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The materials which follow, including computer source code 
and file layouts, are provided in the interest of full 
disclosure and are illustrative of one preferred embodiment of 
the invention entitled "METHOD AND SYSTEM FOR GENERATING 
STATISTICALLY-BASED MEDICAL PROVIDER UTILIZATION PROFILES." 
Numerous other embodiments of the invention and the inventive 
concept may include materials which differ from the materials 
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present invention, and the materials provided herein are not 
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# 

n Module Name : Pp_comp.4gl 

n Version. Edit: 1.0 

# Oate Written: 04/01/94 

U Written By : Rodney R. Fredette 

U 

# Description: This program counts the number of patients and EOCs 

# within a user specified index code. Also counts the 
U number of patients with complicating factors and the 
U number of EOCs with complicating factors. 

n 

U Edit History: 

U Edit Date By Reason 

# — - — 

# 1 4/7/94 rrf add logic to create a temp index table which 

# combines the data from the index_detail table 
U with associated data from the index_global 

# table to form a new temporary index_detail 

# table with all necessary data. Also populate 

# the new EOC table with each occurence of an EOC 

# j*=i as determined by this programs logic. 

« :Q 

# 2 = 5/25/94 rrf change logic for building TEMP_DATA table which 

n ;S which holds all detail for related codes. Now 

U only retrieve detail data for patients who have 

tt ■. 2 at least one icd9 code in the index (indicator = 

n \z£ "I" in the TMPJNDEX table. 

U~-\'-\ 

# ^ 



database eds 

n I s * 

globkts 
define 

i3q_text char(400), 
jyquote char(1) f 
ifipd record like gendbs:prtdev.*, 

'# 

U the following are user supplied variable. 
# 

ir record # ir = input record, data from user 

index like index_detai I. index, 

ok_yn char<1) #Is data input correct? 

end record, 
l ni t_f lag smallint, 
q_text char(400), 
quote chard) 
end globals 



main 

define 

i record 



indicator like i ndex_det a i I. indicator 
end record, 
record 

date_of_serv like e_l ine.date_of_serv, 

pos like e_line.pos, 

tos like e_line.tos, 

proc like e_line.cpt, 

mod_1 like e_line.mod_1, 



new_cat 
eoc_prof i le 
prev_eoc, 
cur_eoc_num 
ces_rdate 
new_stat 
msg 

passed, 

,^cur_by 

j^ok.f lag, 

pj count, 

|^!i count 
ill , 

.--rule_err 
"^prevjaat 
; £iprev_rel 
; ?Hprev_sex 

clear screen 
de-fcer interrupt 

cjaM startLog("pp_comp. log") 



icdl 
charge 
end record, 

record like e_claim.*, 

record 
patient 
relationship 
sex 

date_of_serv 
cpt 
icdl 

category 
end record, 

like category. category, 
like qual jnaster.prof i le, 

integer, 
date, 

char(2), 
char(75), 

smal lint, 



like e_line.icd1, 
I ike e_l ine. charge 



like exclaim. patient, 
like e_claim.retationship, 
I ike exclaim. sex, 
tike e_Line.date_of_serv, 
like e^line.cpt, 
like e_line.icd1, 
Like category. category 



integer, 
char(2), 

like e_c I aim. pat lent, 
tike e_c I aim. relationship, 
like e claim. sex 



initialize ir.* to null 



n Check for command Line arguments 
# 

if num_args() >= 1 then 

let ir. index = upshif t(arg_val(1 )) 
else 

Let msg = *Pp_comp:Must supply index code on comand line! 1 
call errorlog(msg) 
call LSendjnail (get_user(), msg) 
exit program 
end if 



let msg = "Starting: ir. index 
call errorlog(msg) 



start report to "pp_comp.rpt" 



call errorlog ("Creating TMPJNDEX table") 
call tMake_index(ir. index) 

n 

# Oo all patient Level qualifying checks first. Determine which 

# patients have data for the user specified index, then build a 

# temporary patient table containing all detail (line) data needed 
U to check qualifying conditions. Currently, this consists of: 




# date_of_serv, cpt, tcd1 

n 

n First build temp table Ctemp_data) containing all data needed 
U for patients who have at least one occurence of the main index 
U 

call errorlog ("building temp_data") 

select unique patient, relationship, sex 
from e_line Ix, e_claim cx, tmp_index ix 
where Ix. e_claim_id = cx.e_ctaim_id and 

Ix.icdl = ix.icd9 and 

ix. indicator in ("I", "MI") and 

cx.e_claim_id != 0 
into temp tmp_patient 

select ex.*, lx.date_of_serv, Ix.pos, Ix.tos, Ix.cpt, 
Ix.modJ, Ix.icdl, Ix. charge, ix. indicator 
from e_line Ix, e_claim cx, tmp_index ix, tmp_patient ip 
where lx.e_claim_id = cx.e_clairnjd and 
Ix.icdl = ix.icd9 and 
cx. pat ient = i p. patient and 
13 cx. relationship = ip.relationship and 
t f% ex. sex = ip.sex and 

^ cx.e_claim_id != 0 

i'^into temp temp_data 

cajl errorlog ("creating index") 

c 'M ate index 1 "- tdl on temp_data(patient, relationship, sex) 

*>:\ 

# create yet another temp table to hold the category info, because 
#pt seems to take too long accessing the CATEGORY table using 
tf'fhe between clause 

chk errorlog ("Making Cat FILE") 

crSte temp table cat_file < 
;p)roc char(5), 

category char(4)) 
in ucrspacel extent size 200; 

prepare get_cat1_state from 

"select mi n( category) from category where ? between beg_cpt and end_cpt" 
declare get_cat1 cursor for get_cat1_state 

declare ins_cat cursor for 

insert into cat_file values (q.cpt, q. category) 
open ins_cat 

declare bld_cat cursor for 

select unique cpt from temp_data 

let i count = 0 

foreach bld_cat into q.cpt 

if int_flag then 
call stop_now() 

end if 

let i count = i count + 1 
if icount mod 100 = 0 then 

let msg a "Cat counts", icount using "<«,«&" 



call errortog (msg) 
end if 

let q. category = " 11 
open get_cat1 using q.cpt 
fetch get_cat1 into q. category 
close get_cat1 

put ins_cat 
end foreach 
close ins_cat 

let msg = "Cat count=", icount using "<«,«&» 
call errorlog (msg) 

create unique index i_catf1 on cat_f i le(proc); 

call errorlog ("Starting Main Process") 

Let quote = "\"" 

p ; Effpare get_cat_state from 

: i=!"select category from cat file where proc = ?" 
declare get_cat cursor for get cat state 

tf^jext scroll thru each patient and use each patients data to fill 
#J| temp table (temp_qual) to be used for qualifer checks 

*il 

create temp table temp_qual ( 
n date_of_serv date, 

cpt char(5), 
i-s, fcd1 char(6), 

category char(4)) 
ih^ucrspacel extent size 100 next size 100; 

declare upat_curs cursor for 
-select patient, relationship, sex, date_of_serv, cpt, icdt 
from temp_data 
order by 1,2,3 

prepare det_temp_data from 

"delete from temp_data where patient = ? and relationship = ? and sex = ?•■ 

prepare det_qual from "delete from temp_qual" 

declare qual_ins cursor for 

insert into temp_qual values (q.date_of_serv, q.cpt, q.icdl, q. category) 
open qua l_ ins 

let icount = 0 
let j count = 0 

call errorlog ("Performing patient qual checks") 
foreach upat_curs into q.* 

if int_flag then 
call stop_now() 

end if 

let q. category = 11 " 
open get_cat using q.cpt 





fetch get_cat into q. category 

if i count = 0 then 

Let prevjjat = q. patient 

let prev_rel = q. relationship 

let prev_sex = q.sex 

end if 



let icount = icount + 1 

if icount mod 1000 = 0 then 

let msg = "UPAT Detail count=", icount using "«, <«,«&" 

call errorlog (msg) 
end if 



if q. patient != prev_pat or 
q. relationship != prev_rel or 
q.sex != prev_sex then 
let jcount = jcount + 1 
if j'count mod 100 = 0 then 

let msg = "Patient count=", jcount using "<,<«,«&» 
call errorlog (msg) 
,ss=i end if 

■■fl 

p close qual_ins 



call qual_check("P") returning passed, eoc_profile, rule_err 

if not passed then 

let msg = "PAT FAIL: prev_pat, 11 - prev_rel, » - ", 

prev_sex, " Rule: rule_err 
call errorlog (msg) 

execute del_temp_data using prev_pat, prev_rel, prev_sex 



end if 

|3 execute del_qual 
iQ open qual_ins 

let prev_pat = q.patient 

let prev_rel = q. relationship 

let prev_sex = q.sex 
end if 



put qual_ins 
end foreach 
# 

# Take care of last patient 
# 

close qual_ins 

call qual_checic( l, P 11 ) returning passed, eoc_profile, rule_err 
if not passed then 

let msg = "PAT FAIL: », q.patient, " - », q. relationship, » - 
q.sex, 11 Rule: rule_err 

call errorlog (msg) 

execute del_temp_data using q.patient, q. relationship, q.sex 
end if 

execute del_qual 

declare ref_curs cursor for 
select * from temp_data 




let i count = 0 

foreach ref_curs into c.*, I.*, i.* 
if int_flag then 

call stop_now() 
end if 

let i count = i count + 1 

if i count mod 10000 = 0 then 

let msg = "count=", i count using "<<,<«,<<&» 

call errorlog (msg) 
end if 

let curjjy = year( I .date_of_serv) - cage U calc birth year 

output to report r_edit(c.*, i.*, cur_by) 

end foreach 

let msg = "count=", i count using "«,<«,<<&" 
call errorlog (msg) 

f ijl 1 s ^ r epo r t r_ed i t 

# : &bke care of qualifying conditions that may make currently valid 
#=f€C's invalid. Delete all patient data found with a complicating code 

prepare del_comp_eoc from 
ijj'delete from eoc where e_claim_id = ?" 

caijl errorlog ("updating Comp Patients") 
declare comp_pat_curs cursor for 

j-^elect unique e_claim_id 

jaj, from e_claim cc, pat_eoc pe 

;^ where cc. patient = pe. pat lent and 

;== cc. relationship = pe. relationship and 

cc.sex = pe.sex 

leF i count = 0 

foreach comp_pat_curs into c.e_claim_id 
let i count = i count + 1 
if i count mod 1000 = 0 then 

let msg = "counts", icount using "«,<«,<<&» 

call errorlog (msg) 
end if 

execute det_comp_eoc using c.e_claim_id 
end foreach 

let msg = "counts", icount using "«,<«,«&" 
call errorlog (msg) 

call errorlog ("done with comp Patients") 
# 

U Perform EOC qualifier checks on all valid EOCs 
# 

call errorlog ("Performing EOC Qualifier Checks") 

declare qeoc_curs cursor for 

select eoc_num, date_of_serv, proc, icdl 
from eoc 

where index = ir. index and 

eoc_status = "V" 
order by eoc_num 




prepare upd_eoc from 

"update eoc set profile = ? where eoc_num = ?'■ 

open qual_ins 
let i count = 0 

foreach qeoc_curs into cur_eoc_num, q.date_of_serv, q.cpt, q.icdl 
if int^flag then 

call stop_now() 
end if 

let q. category = " " 
open get_cat using q.cpt 
fetch get_cat into q. category 

if i count = 0 then 

let prev_eoc = cur_eoc_num 
end if 

let i count = i count + 1 

if i count mod 1000 = 0 then 
Q let msg = "QEOC count='\ icount using "«,<«,«&" 
; n call errorlog (msg) 
p=end if 

:^jif cur_eoc_num != prev_eoc then 
; « close qual_ins 

let eoc_profile = " " 
* call qual_check( H E") returning passed, eoc_profile, rule_err 
execute upd_eoc using eocjrofile, prev_eoc 

[""* execute del_qual 
i 8 ^ open qua I ins 

O 

5 L? Let prev_eoc = cur_eoc_num 
; yend if 

put qual_ins 
end foreach 
U 

# Take care of last patient 
# 

close qua l_ ins 

let eocjjrof i le = " " 

call qual^checkC'E") returning passed, eoc_profile, rule_err 
if not passed then 

let msg = "EOC FAIL: cur_eoc_num, 11 Rule: " f rule_err 

call errorlog (msg) 

let new_stat = rule_err 
end if 

execute upd_eoc using eocjarofile, cur_eoc_num 

n 

# Grab the category based on procedure code 

call errorlog ("Appending Category data") 

prepare upd_eoc_cat from 

"update eoc set category = ? where proc = ?" 



declare cat_curs cursor for 
select unique proc from eoc 
where index = ir. index 



let i count = 0 
let j count = 0 

foreach cat_curs into I. proc 
let i count = i count + 1 
if i count mod 100 = 0 then 

let msg = "Unique Proc Count: i count using »<<,«&■< 

" New Cat Count: Jcount using '■«,«&» 
call errorlog(msg) 
end if 



let new_cat = " n 
open get_cat using I. proc 
fetch get_cat into new_cat 
if status != not found then 
let jcount = jcount ♦ 1 
execute upd_eoc_cat using new_cat, I. proc 
Hend if 

close get_cat 
eiwi foreach 

■ s%? 

Ijst msg = "Unique Proc Count: i count using "«,«&", 
\f." New Cat Count: jcount using ■■«,<<&" 
call error log (msg) 



le't msg = "Done: 11 , ir. index 
ball errorlog (msg) 
endjmlin 

repbft r_edit(c, l # i, curjay) 
deJine 

-0 i record 

; 0 indicator like index_detai I. indicator 

end record, 

I record 

date_of_serv I i ke e_l ine.date_of_serv, 
pos like e_l ine.pos, 

tos like e_line.tos, 

proc like e_line.cpt, 

mod_1 like e_line.mod_1 , 

icdl like e_line.icd1, 

charge like e_line. charge 

end record, 

c record like exclaim.*, 

cur_by small int, 

cur_eoc_num integer, 

cur_status like eoc.eoc_status, 

co_name, 

hdr_l inel, 

hdr_text, 

hdr2_text char(78), 
xl, x2, x3 smallint, 
ascii_val char (30), 

new_status like eoc.eoc_status, 

pr ev_dos date. 



ok_flag, 




winjnax, #3 ire of EOC window 

eoc_cnt_for _pat, 

cur_eoc_is_bad, 

an_eoc_was_bad sma U i nt , 

eocj:nt, 

pat_cnt, 

eoc_comp, 

pat^comp, 

grp_tot_eoc_comp integer 

output 

top margin 0 
left margin 0 
bottom margin 0 
page length 66 



# order by c. patient, c. relationship, cur_by, c.sex, I .date_of_serv 
order by c. patient, c, relationship, c.sex, I ,date_of_serv 

format 

first page header 
W let q_text = 

; y "select count (*) from tmp_ index where icd9 = ? and 

<§= "indicator = ", quote, "C", quote 

i^J prepare cnt_compl ic_state from q_text 

'--J declare cnt_complic cursor for cnt_compl ic_state 

m# 

Get EOC window size for this index 

, select beg_win into winjnax 
from window 
where staging in 

(select staging from index where index = ir. index) 

^ i f winjnax is null or win_max <= 0 then 
5? call error log ("Invalid EOC window") 
™ exit program 

end if 

# 

U create temporary table to store patients who 'have at lease one 

# complicating factor. Later, all the EOC status for this patient will 

# will tbe set to 'CP 1 
# 

create temp table pat_eoc ( 

patient char(15), 

relationship char<1), 

sex char(1) ) in ucr spacer- 

declare ins_pat_eoc cursor for 

insert into pat_eoc values (c. patient, c. relationship, c.sex) 
open ins_pat_eoc 

declare eoc_ins cursor for 
insert into eoc values 

(cur_eoc_num, ir. index, cur_status, " i.*, I.*, c.e_claim_id, " 11 ) 
open eoc_ins 

select max(eoc_num) into cur_eoc_num from eoc 
if cur_eoc_num is null or cur_eoc_num <= 0 then 
let cur eoc num = 1 




end if 

let eoc_cnt = 0 

Let pat_cnt = 0 

let eoc_comp = 0 

let pat_comp = 0 

let grp_tot_eoc_comp = 0 

let hdr_text = "Care Trends EOC Comparison Report" 

let hdr2_text = "For Index Code: ir. index 

let cojiame = "MEDICOOE, INC." 

let xl = 41 - < Length <co_name) / 2) 

let x2 = 41 - (Length(hdr_text) / 2) 

Let x3 = 41 - (length(hdr2_text) / 2) 

n 

# Check if I/O device needs to be configured 
U 

let asci i_val = " 11 

call parse_asci i(pd.esc_code, "N") returning ok_flag, ascii_val 
if ok_flag then 
„., print ascii_val 
Welse 
™ print 
't^end if 

tJ print 

IJl column 1, "Date: ", today using "MM/DD/YY", 

IJl column x1, co_name clipped, 

%| column 65, "Page: ", pageno using "<,«#" 

j^print 

column 01, "Time: time, 

column x2, hdr_text clipped 

:=» 

,5= let hdr_line1 = 

column 1, l, pp_comp.4gl l », 

~ column x3, hdr2_text clipped 

print hdr_line1 
skip 5 lines 

page header 
pr i nt 

column 01, "Date: », today using "MM/DD/YY", 

column x1, co_name clipped, 
column 65, "Page: ", pageno using "«#» 

print 

column 01, "Time: », time, 

column x2, hdr_text clipped 

print hdr_line1 
skip 5 Lines 

before group of c.sex 

let pat_cnt = pat_cnt ♦ 1 
let eoc^cnt = eoc_cnt ♦ 1 
let prev_dos = I .date_of_serv 
let cur_eoc_is_bad = false 
let an_eoc was bad = false 




let eoc_cnt_for_pat = 1 
let cur_status = "V" 
let cur_eoc_nun * cur_eoc_nun ♦ 1 
# print "rel= ", c. relationship, " sex= c.sex 

n 

# Take care of the first qualifying condition that may make the patient 

# invalid. The patient history must contain at least two related codes. 

# if not, then set the US column * "OP" (disQualif ied Patient). 

# Set ok_flag = false so no EOC logic will be done. 
# 

let ok_flag = true 

on every row 

open cnt_complic using l.icdl 
fetch cnt_complic into ok_flag 
close cnt_complic 

if ok_flag then 
U 

# we have encountered a complicating ICO, but has this EOC 

# already been flagged as bad? If not, then add 1 to the running 
Q # total of the number of EOC's with complicating factors <E0C_COHP) 

'S # 

iC if not cur_eoc_is_bad then 
llj let eoc_comp = eocjromp ♦ 1 

let an_eoc_was_bad = true 
\j\ let cur_eoc_is_bad = true 

\j\ let cur_status = "C" 

y end if 
end if 

u # 

# Now look for a gap in service dates of 60 or more days. If one 
. # is found then a new EOC is starting. 

5 * 

s jj 

™ if I ,date_of_serv - prev_dos >= win_max then 
iy # 

# new EOC 
# 

let eoc_cnt = eoc_cnt + 1 
let cur_eoc_is_bad = false 
let eoc_cnt_f or_pat = eoc_cnt_for_pat + 1 
let cur_eoc_num = cur_eoc_num ♦ 1 
let cur_status = "V M 
end if 

let prev_dos = I ,date_of_serv 

put eoc_ins 

after group of c.sex 
flush eoc_ins 

if an_eoc_was_bad then 
put ins_pat_eoc 

let grp_tot_eoc_comp = grp_tot_eoc_comp + eoc_cnt_for _j>at 
let pat_comp = pat_comp ♦ 1 

end if 



on last row 




close eoc_ins 
close ins_pat_eoc 

print 

column 56, "X of" 

print 

column 10, "Totals:", 
column 34, "Count", 
column 45, "Comp", 
column 56, "Count" 

print 

column 10, " », 

column 34, " ", 

column 45, ■■ ", 

column 56, " " 

print 

column 10, "Patient", 

column 30, pat_cnt using "#,###,##&", 
'J column 40, pat_comp using "#,*##,##&», 
; y column 54, <pat_comp / pat_cnt * 100. 0) using "m.^fiX" 

imprint 

Sf column 10, "EOC", 

LO column 30, eoc_cnt using "#, #*#,##&", 

jjl column 40, grp_tot_eoc_comp using "#,#*#,##&», 

>.f column 54, <grp_tot_eoc_comp / eoc_cnt * 100.0) using "##&.&&X ,> 

M 

i-Ski p 2 lines 
ijprint 

column 10, "EOC Window: ", winjnax using "«&" 
end report 

ifi 

function init_qual_sqlO 
Le'f^quote = "\"» 

let q_text = 

"select * from qualjnaster where index = ", quote, ir. index, quote, 
" and (scope = quote, "B", quote, " or scope = ?) 
" order by profile desc" 

prepare mast_state from q_text 

declare mast_curs cursor for mast_state 

prepare grp^state from 

"select * from qual_group where rule_group = ? order by rule_type, rule_id" 

declare grp_curs cursor for grp_state 

# 

# Rule type II requires 2 or more occurences of the index range in the 

# pat. history, but they must occur on different 0OS. So group by DOS and 

# if more than one row is returned, then everything is dandy. 

# If cat_cpt is null use ranges for indicator. Otherwise use 

# specific icd9 code in the column qual_ic.cat_cpt 

# 

U changed 6/15/94 by rrf : no longer prepared here, but within the qual_chk 
U function itself. The cursor is built based on qual_ic information. 
# 

prepare ic_state from 




"select * from qual_ic where rule_type = ? and rule_id = ? M 
declare ic_curs cursor for ic_state 

prepare cnt_cat_state from 

"select count (*) from temp_qual where category = ?" 
declare cnt_cat cursor for cnt_cat_state 

prepare cc_state from 

"select * from qual_cc where rule_type = ? and rute_id = ?" 
declare cc_curs cursor for cc_state 



let init_flag = true 
end function 



function qual_check< in_scope) 



def i ne 

in_scope 
qm 

qg 
q» 

_qc 

Qcur^dos 
iyprof i le_num 
,pf irst_row, 
yok.flag, 
's. |cnt, 
! r| passed, 
,:=f;rule _passed 
.~ ihold status 



chard), #<P)atient or (E)0C 

record like qualjnaster.*, 
record like qual_group.*, 
record like qual_ic.*, 
record like qual_cc.*, 
date, 

like qualjnaster.prof i le, 

# boolean used by II rule 



# Data passed Qual checks 



smallint, 
integer 



(et passed = true 

let profile_num = null 



f t ini t — f lag is null or not init_flag then 
i= fcall init_qual_sql<) 
tSk if 

^0 

initialize qm.* to null 
open mast_curs using in_scope 
fetch mast_curs into c|n.* 
let hold^status = status 
while hold_status != not found 

open grp_curs using qpi.ru I e_g roup 

fetch grp_curs into qg.* 

while status 1= not found 
case 

when qg.rule_type = "M" 
# 

# build select statement based on detail rules then 

# derive count of rows over different DOS 
# 

let q_text = 

"select date_of_serv, count (*) from temp_qual, tmp_ index 
"where icdl = icd9 " 



let first row = true 



open ic_curs using qg.rule_type, qg.rule_id 
fetch ic_curs into qi.* 
while status != not found 



if f ld_is_null(qi .cat^cpt) then 
if first_row then 

let firswow = false 

let q_text = q_text clipped, 

" and (tmp_ index. indicator = » f 
quote, qi . indicator, quote 

else 

let q^text = q_text clipped, 

or tmp_index. indicator = 
quote, qi. indicator, quote 

end if 
else 

if first_row then 

let first_row = false 

let q_text = q_text clipped, 

" and (icdl = 11 , quote, qi.cat_cpt, quote 

else 

let q_text = q_text clipped, 

" or icdl = quote, qi.cat_cpt, quote 

end if 
end if 

fetch ic_curs into qi,* 
end wh i I e 

let q_text = q_text clipped, ") group by 1" 
let cnt = 0 

prepare cnt_ind_state from q_text 
declare cnt_ind cursor for cnt_ind_state 

open cnt_ind 

fetch cnt_ind into cur_dos, ok_flag 
while status != not found 
let cnt = cnt + 1 

fetch cnt_ind into cur_dos, ok_flag 
end while 
close cnt_ind 

if cnt >= qg.num_ required then 

let ruLe_passed = true 
else 

let rulejaassed = false 
end if 
# 

# If the qg. logical is false, then invert the results of 

# this rule check, ie. False = true, true = false 
# 

if qg. logical = "F" then 
if rulejiassed then 

let rule_passed = false 
else 

let rule_passed = true 
end if 
end if 
# 

# if ruLe_passed is false then none of the detail parts 

U of the rule passed COR* boolean) so the patient fails. 

# stop checking. 

n 



if not rule_passed then 

let passed = false 

exit while 
end if 

when qg.rule_type » 11 1 C" 
let rule_passed = false 
let cnt = 0 

open ic_curs using qg*rule_type, qg.ru I e_id 
fetch ic_curs into qi.* 
while status != not found 

open cnt_cat using qi.cat_cpt 

fetch cnt_cat into ok_flag 

close entreat 

let cnt = cnt + ok_flag 

if cnt >= qg.numj-equired then 

tet rule_passed = true 

exit while 
end if 

fetch ic_curs into qi.* 
end wh i I e 
# 

# If the qg. logical is false, then invert the results of 

# this rule check, ie, False = true, true = false 
U 

if qg. logical = "F" then 
if rule_passed then 

let rule_passed = false 
else 

let rule_passed = true 
end if 
end if 
# 

# if rule_passed is false then none of the detail parts 

# of the rule passed ('OR' boolean) so the patient fails. 

# stop checking. 
# 

if not rule_passed then 

let passed = false 

exit while 
end if 

when qg.rule_type = "CC" 

open cc_curs using qg.rule_type, qg.rule_id 
fetch cc_curs into qc* 
while status != not found 

open cnt_cat using qc.cat_cpt1 

fetch entreat into cnt 

close entreat 

if cnt >= 1 then 

open entreat using qc.cat_cpt2 
fetch cnt_cat into cnt 
close cnt_cat 

if cnt < qg.num_required then 
if qg. logical = "T" then 

let passed = false 
end if 




else 

if qg. Logical * "F" then 

let passed = false 
end if 
end if 
end if 

if not passed then 

exit while 
end if 

fetch cc_curs into qc* 
end while 

if not passed then 

exit whi le 
end if 
end case 

fetch grp_curs into qg.* 
end wh i I e 

i£f f° r EOC checks a pass means that a profile has been assigned so exit 
£# for patients, a failure (not pass) means the client has failed a 
qualifying condition so don't bother checking any others (exit). 

= l_f 

I f$f passed then 
.1™ if in_scope = "E" then 
\*\ exit while 
^ end if 

. if in_scope = "P" then 
j 33 exit while 
^ end if 
Qnd if 

= Oetch mast_curs into qpi.* 
let hold_status = status 
if not passed then 

if hold_status 1= notfound then 

let passed = true 
end if 
else 

exit whi le 
end if 
end while 

let profilejum = <yn. profile 
return passed, prof i le_nun, qi.rulejd 
end function 
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1 M&GNo. 12344.2-US-C1 



2 METHOD AND SYSTEM FOR GENERATING STATISTICALLY-BASED 

3 MEDICAL PROVIDER UTILIZATION PROFILES 

4 Microfiche Appendix 

5 This specification includes a Microfiche Appendix which includes 1 



6 page of microfiche with a total of 37 frames. The microfiche appendix includes 

7 computer source code of one preferred embodiment of the invention. In other 

8 embodiments of the invention, the inventive concept may be implemented in other 

9 computer code, in computer hardware, in other circuitry, in a combination of these, or 

10 otherwise. The Microfiche Appendix is hereby incorporated by reference in its entirety 

1 1 and is considered to be a part of the disclosure of this specification. 

12 I. Background of the Invention 

13 A. Field of the Invention 

14 The invention relates to methods and systems for analyzing medical 

15 claims histories and billing patterns to statistically establish treatment utilization 

16 patterns for various medical services. Data is validated using statistical and clinically 

17 derived methods. Based on historical treatment patterns and a fee schedule, an accurate 

18 model of the cost of a specific medical episode can be created. Various treatment 

19 patterns for a particular diagnosis can be compared by treatment cost and patient 

20 outcome to determine the most effective treatment approach. It is also possible to 

21 identify those medical providers who provide treatment that does not fall within the 

22 statistically established treatment patterns or profiles. 
23 

24 B. The Background Art 

25 It is desirable to compare claims for reimbursement for medical services 

26 against a treatment pattern developed from a large body of accurate medical provider 

27 billing history information. Although in the prior art some attempt was made to 

28 compare claims for reimbursement for medical services to a normative index, the prior 

29 art did not construct the normative index based on actual clinical data. Rather, the prior 

30 art based the normative index on a subjective conception (such as the medical 

31 consensus of a specialty group) of what the proper or typical course of treatment should 
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1 be for a given diagnosis. Such prior art normative indices tended to vary from the 

2 reality of medical practice. In the prior art, automated medical claims processing 

3 systems, systems for detecting submission of a fraudulent medical claims, and systems 

4 for providing a medical baseline for the evaluation of ambulatory medical services were 

5 known. Documents which may be relevant to the background of the invention, 

6 including documents pertaining to medical reimbursement systems, mechanisms for 

7 detecting fraudulent medical claims, and related analytical and processing methods, 

8 were known. Examples include: U.S. Pat. No. 4,858,121, entitled "Medical Payment 

9 System" and issued in the name Barber et al. on Aug. 15, 1989; U.S. Pat. No. 

10 5,253,164, entitled "System and Method for Detecting Fraudulent Medical Claims Via 

1 1 Examination of Service Codes" and issued in the name of Holloway et al. on Oct. 12, 

12 1993; U.S. Pat. No. 4,803,641, entitled "Basic Expert System Tool" and issued in the 

13 name of Hardy et al. on Feb. 7, 1989; U.S. Pat. No. 5,658,370, entitled "Knowledge 

14 Engineering Tool" and issued in the name of Erman et al. on Apr. 14, 1987; U.S. Pat. 

1 5 No. 4,667,292, entitled "Medical Reimbursement Computer System" and issued in the 

16 name of Mohlenbrock et al. on May 19, 1987; U.S. Pat. No. 4,858,121, entitled 

17 "Medical Payment System" and issued in the name of Barber et al. on Aug. 15, 1989; 

18 and U.S. Pat. No. 4,987,538, entitled "Automated Processing of Provider Billings" and 

19 issued in the name of Johnson et al. on Jan. 22, 1991, each of which is hereby 

20 incorporated by reference in its entirety for the material disclosed therein. 

2 1 Additional examples of documents that may be relevant to the 

22 background of the invention are: Leape, "Practice Guidelines and Standards: An 

23 Overview," QRB (Feb. 1990); Jollis et al., "Discordance of Databases Designed for 

24 Claims Payment versus Clinical Information Systems," Annals of Internal Medicine 

25 (Oct. 15, 1993); Freed et al., "Tracking Quality Assurance Activity," American College 

26 of Utilization Review Physicians (November, 1988); Roberts et al, "Quality and Cost- 

27 Efficiency," American College of Utilization Review Physicians (November, 1988), 

28 Rodriguez, "Literature Review," Quality Assurance and Utilization Review - Official 

29 Journal of the American College of Medical Quality (Fall 1991); Elden, "The Direction 

30 of the Healthcare Marketplace," Journal of the American College of Utilization Review 

31 Physicians (August 1989); Rodriguez, "Literature Review," Quality Assurance and 
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1 Utilization Review - Official Journal of the American College of Medical Quality (Fall 

2 1991); Roos et al., "Using Administrative Data to Predict Important Health Outcomes," 

3 Medical Care (March 1988); Burns et al., "The Use of Continuous Quality Improvement 

4 Methods in the Development and Dissemination of Medical Practice Guidelines, QRB 

5 (December, 1992); Weingarten, "The Case for Intensive Dissemination: Adoption of 

6 Practice Guidelines in the Coronary Care Unit," QRB (December, 1992); Flagle et al., 

7 "AHCPR-NLM Joint Initiative for Health Services Research Information: 1992 Update 

8 on OHSRI," QRB (December, 1992); Holzer, "The Advent of Clinical Standards for 

9 Professional Liability," QRB (February, 1990); Gottleib et al., "Clinical Practice 

10 Guidelines at an HMO: Development and Implementation in a Quality Improvement 

1 1 Model," QRB (February, 1990); Borbas et al., "The Minnesota Clinical Comparison and 

12 Assessment Project," QRB (February, 1990); Weiner et al., "Applying Insurance Claims 

13 Data to Assess Quality of Care: A Compilation of Potential Indicators," QRB 

14 (December, 1990); Wakefield et al, "Overcoming the Barriers to Implementation of 

15 TQM/CQI in Hospitals: Myths and Realities," QRB (March, 1993); Donabedian, "The 

16 Role of Outcomes in Quality Assessment and Assurance," QRB (November, 1992); 

17 Dolan et al., "Using the Analytic Hierarchy Process (AHP) to Develop and Disseminate 

18 Guidelines," QRB (December, 1992); Hadorn et al., "An Annotated Algorithm 

19 Approach to Clinical Guideline Development," JAMA (Jun. 24, 1992); Falconer et al., 

20 "The Critical Path Method in Stroke Rehabilitation: Lessons from an Experiment in 

21 Cost Containment and Outcome Improvement," QRB (January, 1993); Reinertsen, 

22 "Outcomes Management and Continuous Quality Improvement: The Compass and the 

23 Rudder," QRB (January, 1993); Mennemeyer, "Downstream Outcomes: Using 

24 Insurance Claims Data to Screen for Errors in Clinical Laboratory Testing," QRB (June, 

25 1991); Iezzoni, "Using Severity Information for Quality Assessment: A Review of 

26 Three Cases by Five Severity Measures," QRB (December 1989); Kahn, "Measuring 

27 the Clinical Appropriateness of the Use of a Procedure," Medical Care (April, 1988); 

28 Wall, "Practice Guidelines: Promise or Panacea?," The Journal of Family Practice 

29 (1993); Lawless, "A Managed Care Approach to Outpatient Review," Quality 

30 Assurance and Utilization Review - Official Journal of the American College of 

3 1 Utilization Review Physicians (May, 1990); Dragalin et al., "Institutes for Quality: 
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1 Prudential's Approach to Outcomes Management for Specialty Procedures," QRB 

2 (March, 1990); Chinsky, "Patterns of Treatment Ambulatory Health Care Management, 

3 Physician Profiling - The Impact of Physician, Patient, and Market Characteristics On 

4 Appropriateness of Physician Practice in the Ambulatory Setting," (Doctoral 

5 Dissertation, The University of Michigan, 1991), published by Concurrent Review 

6 Concurrent Review Technology, Inc., Shingle Springs, California; "Patterns of 

7 Treatment Ambulatory Health Care Management, Implementation Guide," published by 
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2 II. Summary of the Invention 

3 It is an object to provide a mechanism for assessing medical services 

4 utilization patterns. The invention achieves this object by allowing comparison 

5 processing to compare an individual treatment or a treatment group against a statistical 

6 norm or against a trend. 

7 It is an object of the invention to provide a mechanism for converting 

8 raw medical providers* billing data into a database. The invention achieves this object 

9 by read, analyze and merge ("RAM") processing coupled with claims edit processing to 

10 achieve a reliable, relevant data set. 

11 It is an object of the invention to provide a mechanism for accurately 

12 determining an episode of care. The invention achieves this object by providing a 

13 sequence of steps which, when performed, yield an episode of care while filtering out 

14 irrelevant and inapplicable data. 

15 It is an object of the invention to provide a method for performing a 

16 look-up of information, that is, providing a mechanism for gaining access to different 

17 parts of the informational tables maintained in the database. This object is achieved by 

18 reviewing the referenced tables for specific codes representing specific diagnoses. The 

19 codes are verified for accuracy. Then tables are accessed to display selected profiles. 

20 Users are then given the opportunity to select profiles for comparison. 

21 It is an object of the invention to provide a method for comparing 

22 profiles. This object is achieved by comparing index codes against historical reference 

23 information. Discovered information is checked against defined statistical criteria. The 

24 process is repeated for each index code and its profiles developed in the history process 

25 as many times as necessary to complete the information gathering. 

26 It is an object of the invention to create, maintain and present to the user 

27 a variety of report products. These reports are provided either on-line or in a hard copy 

28 format. The process of creating, maintaining and presenting these reports is designed to 

29 present relevant information in a complete and useful manner. 

30 It is an object of the invention to provide a mechanism for creating a 

3 1 practice parameter database. This object is achieved in the invention by repetitive 
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1 episode of care processing and entry of processed episode of care data into a data table 

2 until the populated data table becomes the practice parameter database. 
3 

4 III. Brief Description of the Drawings 

5 FIG. 1 depicts steps performed in the method of the invention to 

6 establish a practice parameter or utilization profile for a particular diagnosis. 

7 FIG. 2 depicts an episode of care for a single disease. 

8 FIG. 3 depicts an episode of care for concurrent diseases. 

9 FIG. 4 depicts potential outcomes for an episode of care. 

10 FIG. 5 depicts phases of an episode of care. 

1 1 FIGs. 6-8 depicts processing of data before episode of care processing 

12 begins. 

13 FIG. 9 depicts episode of care processing. 

14 FIG. 10 depicts principle elements of the invention and their relationship 

15 to each other. 

16 FIG. 1 1 depicts the process of the preferred embodiment of the Read, 

1 7 Analyze, Merge element of the invention. 

18 FIG. 12 depicts the process of the preferred embodiment of the Episode 

19 of Care element of the invention. 

20 FIG. 13 depicts the process of the preferred embodiment of the Look-up 

2 1 element of the invention. 

22 FIG. 14 depicts the process of the preferred embodiment of the Subset 

23 Parameter Look-up component of the Look-up element of the invention. 

24 FIG. 15 depicts the process of the preferred embodiment of the Profile 

25 Comparison element of the invention. 
26 

27 IV. Detailed Description of the Preferred Embodiment 

28 The invention includes both a system and a method for analyzing 

29 healthcare providers' billing patterns, enabling an assessment of medical services 

30 utilization patterns. When the invention is employed, it can readily be seen whether a 

3 1 provider or multiple providers are overutilizing or underutilizing services when 
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1 compared to a particular historical statistical profile. The statistical profiles of the 

2 invention are a statically-derived norms based on clinically- validated data which has 

3 been edited to eliminate erroneous or misleading information. The profiles may be 

4 derived from geographic provider billing data, national provider billing data, the 

5 provider billing data of a particular payor entity (such as an insurance company) or 

6 various other real data groupings or sets. Multiple informational tables are used in the 

7 database of the preferred embodiment of the invention. These include a Procedure 

8 Description Table, ICD-9 Description Table, Index Table, Index Global Table, Index 

9 Detail Table, Window Table, Procedure Parameter Table, Category Table, Qualifying 

10 Master Table, Specialty Table, Zip/Region Table, Specialty Statistic Table, Age/Gender 

1 1 Statistic Table, Region Statistic Table, Qualifying Index Table, Qualifying Group 

12 Table, Category Parameter Table, and Duration Parameter Table. ICD 9 codes or ICD 

13 (International Classification of Diseases, generically referred to as a disease 

14 classification) codes as they are generally referred to herein are used in the preferred 

15 embodiment. In other embodiments of the invention other codes could be used, such as: 

16 predecessors or successors to ICD codes or substitutes therefor, such as DSM 3 codes, 

17 SNOWMED codes, or any other diagnostic coding schemes. These tables are described 

18 in detail as follows. It should be noted, however, that these tables described are used by 

19 the inventors in one implementation of the invention, and that the inventive concept 

20 described herein may be implemented in a variety of ways. 
21 

22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
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1 

2 
3 
4 
5 



PROCEDURE DESCRIPTION TABLE 

This table identifies and validates five years of both CPT (Current Procedural 
Terminology, generically referred to as an identifying code for reporting a medical 
service) and HCPCS level II procedure codes. The lifetime occurrence maximum and 
follow-up days associated with a procedure code are also located in this table. 



6 


Code (Key) 


Alpha/Numeric 


5 


Standard CPT or HCPCS (5 Years including 


7 








Modifiers) 


8 


Sub-Code 


Character 


2 


* = Starred Procedures 










N = New Codes Current Year 


9 








jj i — ueietea v^oae L/Urrent i ear 


1 n 








D2 = Deleted Code Previous Year 


ll 








D3 = Deleted Code Third Year 


12 








D4 = Deleted Code Fourth Year 


13 








C = Changed Description 


14 
15 


Life Time 
Occurrence 


Numeric 


2 


Number = Count of occurrence in a lifetime 
Blank = Not applicable 


Follow Up 


Numeric 


3 


Number of Follow up Days to procedure. 


16 


Days 








17 


Description 


Character 


48 


Standard abbreviated description 


18 


Total 




60 





19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



USE: 



This table can validate CPT and HCPCS codes. 
Five years of codes will be kept. 
Give a brief description of the code. 

Gives the maximum number of occurrences that this code can be done in a 
lifetime, if applicable. (Programming not addressed, to date) 
Give the number of follow up days to a procedure. (Programming not addressed, 
to date) 

Modifiers are stored in this table with a "099" prefix (i.e., the 80 modifier is 
"09980") with a description of the modifier. 
This table interrelates with: 
- Parameter Tables 
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1 

2 
3 
4 
5 
6 
7 
8 



- Category Table 

- Qualifying Tables 

- Specialty Table 

- CPT Statistic Table 

ICD-9 DESCRIPTION TABLE 

This table identifies and validates five years of diagnosis codes. It also 
contains a risk adjustment factor for each diagnosis. 



9 


ICD-9 Code (Key) 


Alpha/Numeric 


5 


Left justified, assumed decimal after 3rd 


10 








position 


11 


Sub-Code 


Character 


2 


N = New Code 


12 








D = Deleted Code 


13 








C = Changed Code 


Indicator 


Character 


1 


* or blank 


14 








* = code requires 4th and/or 5th digits to be 


15 








specific 


16 


Risk 


Alpha/Numeric 


2 


Overall Classification of Disease 


17 


Description 


Character 


48 


Standard abbreviated description 



18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



Total 
USE: 



58 



This table can validate ICD codes. 
Five years of codes will be kept. 
Give a brief description of the code. 

Show if the code is incomplete and in need of a fourth or fifth digit. An ICD 
code which should have a 4th and/or 5th digit is listed with an "*". 
This file interrelates with: 

Index Table 

Index Detail Table 

Index Global Table 

Qualifying Master Table 

Family Table 
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2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



- All Parameter Tables 

INDEX DETAIL TABLE 

This table identifies ICD-9 codes relevant to each specific index code 
and is used to drive the search for each episode of care. ICD-9 codes have been given 
an indicator which determines whether or not the associated CPT code should be 
included in the episode of care. Also, an indicator may cause exclusion of any specific 
patient record from an episode of care analysis. 



Index Code 


Alpha/Numeric or 
character 


5 


Left justified assumed decimal after 3rd 
position. 


Indicator 


Character 


2 


I = Index code 

R = Related 

S = signs/symptoms 

RO = Rule out 

C = complications (exclude) 

M = miscoded 

V = Vcodes 

MI = Miscoded Index 


Beg-ICD 


Alpha/Numeric 


5 


ICD-9 Beginning Range Code 


End-ICD 


Alpha/Numeric 


5 


ICD-9 Ending Range Code 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



17 



This table drives the search for the Episode of Care (EOC) and is keyed off the 
Index Code field. 

Other codes to be included in the parameter search are specified in the indicator 
field. 

ICD codes with an indicator of "C" when found in a patient history will disqualify 
the entire patient from the EOC process. 

"Some Index Codes are listed in part with "?" and "??" to exhibit that it does not 
matter what the trailing 4th and/or 5th digit is, the record is to be accessed for the 
parameter. For example, the Index code may be 701??, meaning that if the first 
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1 three digits of the ICD code start with 701 then use the code regardless of what the 

7 

4th and/or 5th digit may be." 

3 

4 • ICD codes maintained in this table are listed as complete as verified by the ICD 
^ description table, with the exception of ICD codes beginning with an indicator of 

g "M". Programming logic should consider this when using "M" codes in the search 

j process. 

g • This table is used for drafting and populating a temporary file built from this table 
g and the Index Global Table based on indicators and keys extrapolated from the 

JO Index table. 

11 

n PROGRAM LOGIC TO ASSIGN EPISODE OF CARE 

^3 • Any patient history with an ICD from the temp file for the chosen Index code is 

14 tagged for possible assignment of Episode of Care. 

1 5 • Perform a search on patient history for any ICD code from temp file with an 

16 indicator of "C". If found, exclude entire patient history from EOC search. 

17 • The qualifying tables are accessed to verify if specific qualifying factors apply to 

1 8 determine if patient history meets criteria for determination of valid episode of 

19 care. (See Qualifying Tables for further explanation) 

20 • The qualifying table is then accessed for further delineation of qualifying 

21 circumstances by EOC. 

22 • A timeline is tracked, by patient, for all potential Episodes of care that may occur 

23 for a given patient history. 

24 • The data is arrayed based on profile classes which are eight subsets of Procedure 

25 categories. An aggregate of all procedures can also be reported. (See Category 

26 Table for further explanation) 

27 • This table interrelates with: 

28 _ ICD Description Table 

29 - Index Table 

30 - Index Global Table 
3 ^ - Parameter Table 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



CPT Statistic Table 
Age/Sex Table 



INDEX TABLE 



This table provides a preliminary step for assigning and accessing 
different tables during the Episode of Care process. This table houses the assignment of 
staging and whether or not the Index Global table should be accessed. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Staging 


Character 


2 


P = preventive 

A - acute 

C = chronic 

L = life threatening 

M = manifestations 


Global Key 


Alpha 


2 


C = complications 

Ml = miscoded medical vcodes 

M2 = miscoded surgical vcodes 

1= medical vcodes 

2 = surgical vcodes 


Indicator 


Character 


2 


C = complications 
V = vcodes 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



12 



Once an Index code has been selected, this table is searched for whether or not the 
global index table needs to be accessed. 

This table assigns the staging for the index code which points to the window table. 
This table interrelates with: 

- ICD Description Table 

- Index Detail Table 
Index Global Table 
Window Table 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



INDEX GLOBAL TABLE 

This table gives a listing of ICD-9 codes common to most Index codes 
for either inclusion in an EOC such as preventive or aftercare, or exclusion of a patient 
history such as medical complications. 



GLOBAL KEY 


Alpha/Numeric 


2 


C - complications 

Ml = miscoded medical vcodes 

M2 = miscoded surgical vcodes 

1 = medical vcodes 

2 = surgical vcodes 


ICD Beginning 


Alpha/Numeric 


5 


ICD-9 Beginning range code 


ICD Ending 


Alpha/Numeric 


5 


ICD-9 Ending range code 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 
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This table is used to identify a generic V Code or complication ICD code to be 

used in an EOC search for any Index code. 

It is triggered by the Index table. 

The surgical Vcodes include all Ml, M2, 1 and 2's. 

Medical Vcodes include Ml and 1. 

A complication ICD code will negate the use of a patient history from the EOC 
search. 

A temporary file for the index code is created based on ICDs extrapolated from 
this table as well as the Index detail table 
This table interrelates with: 

ICD Description Table 
- Index Table 

Index Detail Table 
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1 WINDOW TABLE 

2 This table contains the time period preceding and following an episode 

3 of care that must be present without any services provided to the patient relating to the 

4 index code or associated codes. These windows are used to define the beginning and 

5 end points of an episode of care. This table is driven from the staging field in the index 

6 table. 



1 


Index Code 


A11_ / 

Alpha/ 


5 


Left justified assumed decimal after 3rd 


8 




Numeric 




position 


9 


Staging Indicator 


Character 


2 


P = Preventive 


10 








C = Chronic, A = Acute 


11 








L = Life threatening, M = Manifestation 


12 


Beginning Window 


Numeric 


3 


Time Period for no occurrence of ICD for 


13 








Index Code 


14 


Ending Window 


Numeric 


3 


Time Period for no occurrence of ICD for 


15 








Index Code 


16 


Update 


Character 


1 


A, C, or Blank 



Total 9 

17 

USE: 

18 

^ • This table is keyed off of the staging indicator and it tells the program how long of 
a "Clear Window" is needed on both ends of this EOC for it to be valid. 

20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
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1 PROCEDURE PARAMETER TABLE 



2 This table contains the specific CPT codes identified for each index code 

3 listed chronologically with associated percentiles, mode, and average. 



4 


Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 


5 








position 


6 


Profile 


Alpha/Numeric 


2 


Mnemonic 


7 


Procedure 


Alpha/Numeric 


5 


CPT, HCPCS 


8 
9 


timeframe 


Alpha/Numeric 


3 


Mnemonic for timeframe or total 


50th percentile 


Numeric 


4 


Beginning percentile range 


50th percentile 


Numeric 


4 


ending percentile range 


10 


75th percentile 


Numeric 


4 


beginning percentile range 


11 


75th percentile 


Numeric 


4 


ending percentile range 


1 2 


95th percentile 


Numeric 


4 


beginning percentile range 


13 


95th percentile 


Numeric 


4 


ending percentile range 


14 


Mode 


Numeric 


3 


Numeric Count 


15 
16 


Count 


Numeric 


7 


Number of EOCs for timeframe 


Sum 


Numeric 


7 


Number of services for timeframe 


Weighting 


Numeric 


6 


Numeric count, assumed decimal (4.2) 


17 


Update 


Character 


1 


A, C, or Blank 


18 


Total 




63 





19 USE: 

20 • This table shows which CPTs are historically billed and statistically how often for 

2 1 a Specific Index Code. 
22 

23 
24 
25 
26 
27 
28 
29 
30 
31 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



CATEGORY PARAMETER TABLE 

This table contains a listing of the procedural categories identified for 
each index code listed chronologically with associated percentiles, mode, and average. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Profile 


Alpha/Numeric 


2 


Mnemonic 


Category 


Alpha/Numeric 


4 


category 


timeframe 


Alpha/Numeric 


3 


Mnemonic of timeframe or total 


50th percentile 


Numeric 


4 


beginning percentile range 


50th percentile 


Numeric 


4 


ending percentile range 


75th percentile 


Numeric 


4 


beginning percentile range 


75th percentile 


Numeric 


4 


ending percentile range 


95th percentile 


Numeric 


4 


beginning percentile range 


95th percentile 


Numeric 


4 


and ending percentile range 


Mode 


Numeric 


3 


Numeric Count, assumed decimal (4.2) 


Count 


Numeric 


7 


Number of EOCs for the timeframe 


Sum 


Numeric 


7 


Number of services for the timeframe 


Update 


Character 


1 


A, C, or Blank 



Total 56 

USE: 

• This table shows which Procedural Categories are historically billed and 
statistically how often for a Specific Index Code. 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



DURATION PARAMETER TABLE 

This table contains the EOC duration distribution for a given Index code. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Profile 


Alpha/Numeric 


2 


Mnemonic 


50th percentile 


Numeric 


4 


beginning range 


50th percentile 


Numeric 


4 


ending range 


75th percentile 


Numeric 


4 


beginning range 


75th percentile 


Numeric 


4 


ending range 


95th percentile 


Numeric 


4 


beginning range 


95th percentile 


Numeric 


4 


ending range 


Mode 


Numeric 


3 


beginning and ending range 


Update 


Character 


2 


A- Add 
C = Change 



Total 
USE: 
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This table gives access to Statistical information about EOC durations of care for a 
given index code. 
It interrelates with: 

- Index Detail table 

- Parameter table 

CATEGORY TABLE 

This Table provides a grouping of CPT codes into categories of similar 



services. 



Category 


Alpha/Numeric 


4 


Mnemonics 


Beg-CPT 


Alpha/Numeric 


5 


Beginning CPT Range 


End-CPT 


Alpha/Numeric 


5 


Ending CPT Range 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



15 
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Procedure codes have been categorized according to most likely type of service 
they may represent. It could be characterized as a sorting mechanism for 
procedure codes. 
The mnemonic used for this category is as follows: 

Ei =Major E and M E 2 =Minor E and M 

Li =Major Laboratory L2 =Minor Laboratory 

R D i =Major Diagnostic Radiology R D 2 =Minor Diagnostic Radiology 
Rti =Major Therapeutic Radiology Rt2 =Minor Therapeutic Radiology 
Oi =Major Oncology Radiology O2 =Minor Oncology Radiology 
M D i =Major Diagnostic Medicine M D 2 ^Minor Diagnostic Medicine 
Mxi =Major Therapeutic Medicine Mt2 =Minor Diagnostic Medicine 
Sdi =Major Diagnostic Surgery Sd2 =Minor Diagnostic Surgery 
Sti =Major Therapeutic Surgery St 2 =Minor Therapeutic Surgery 
Ai =Major Anesthesia A2 =Minor Anesthesia 
Pi =Pathology J=Adjunct 

Categories are also used for arraying Episodes of Care into profile classes or can 
be reported as an aggregate. The subsets of the aggregate are: 

0 Common Profile 

1 Surgery/Radiation/Medicine Profile 

2 Medicine/Radiation Profile 

3 Surgery/Radiation Profile 

4 Surgery/Medicine Profile 

5 Radiation Profile 

6 Medicine Profile 

7 Surgery Profile 

This table interrelates with: 
- Parameter Table 
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1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



- Qualifying Tables 

- Procedure Table 

QUALIFYING MASTER TABLE 
This table provides a preliminary step for determining qualifying 
circumstances that may eliminate a patient history for determination of an Episode of 
Care. It also provides the initial sort of an episode of care for a specific profile class. 



Index Code 


Alpha/Numeric 


5 


Left justified, assumed decimal after 3rd 
position 


Scope 


Alpha 


1 


P = Patient 

E = Episode of Care 

B - Both 


Profile 


Alpha/Numeric 


2 


Mnemonic or Blank 


Group 


Alpha/Numeric 


5 


Correlates to group ID in Qualifying Group 
Table 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



14 



Preliminary step in EOC qualifying process. 
This table interrelates with: 

- Index Detail Table 

- Qualifying Group Table 

The Scope field of the Qualifying Master Table outlines which set of qualifying 
circumstances are to be applied. The values of the Scope field include P=patient 
level, E=Episode of Care level, or B= both. 

The Profile field is numbered based on the 8 different profiles (also outlined under 
the category table. If blank, a profile is not relevant. They are as follows: 



20 



0. Common Profile 

1 . Surgery/Medicine/Radiation Profile 

2. Medicine/Radiation Profile 

3. Surgery/Radiation Profile 

4. Surgery/Medicine Profile 

5. Radiation Profile 

6. Medicine Profile 

7. Surgery Profile 

The Group field assigns a 5 byte mnemonic that establishes a set of qualifying 
rule sets for a given index code. This field keys directly to the Qualifying Group 
Table. The majority of the groups relate to profile classes. 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



QUALIFYING GROUP TABLE 

This table groups certain qualifying circumstances to aid in an efficient 
search for data meeting the criteria. 



Group 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position 


Rule Type 


Alpha/Numeric 


2 


II = Index Code specific rule 

IS = specific ICD code rule 

IC = multiple ICD to category rule 

CC = Multiple code rule 

CS = code specific rule 

IG = ICD to gender rule 

IA = ICD to age rule 


Logical 


Alpha/Numeric 


1 


T = True F = False (toggle) 


Rule Identifier 


Alpha/Numeric 


1 


M = Male F = Female if IG rule type 


Number required 


numeric 


2 


number value 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



15 



This table groups all rules qualifying EOCs. 
This table interrelates with: 

- Qualifying Index Table 
Qualifying Code Table 

- Qualifying Master Table 

A rule type (or rule types) is assigned by group delineating if the rule applies to a 
single or multiple ICD, single or multiple CPT or category or any combination 
thereof. 

The Rule Type is a mnemonic which assigns a common type of logic that is to be 
implemented in the search for the qualifying circumstances. It is possible that the 
same rule type could be associated with many different rule identifiers. The rule 
type will also point to either the Qualifying Index Table or the Qualifying Code 
Table. 

The following is a listing of the rule types. (One skilled in the art would 
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1 understand that additional rule types and associated programming logic may be 

2 implemented): 
3 

4 Rule Types associated with Qualifying Index Table: 

5 

6 II This related directly to the Index code only. 

7 

8 IC This rule is for any indicated ICD code associated with the Index code as it 

9 relates to a category or procedure. 
10 

1 1 IS This rule is for a specific indicated ICD code associated with the Index code as 

12 it relates to a category or procedure. 
13 

14 IG This rule is for any indicated ICD code associated with the Index code as it 

15 relates to age. 
16 

17 Rule Types associated with Qualifying Code Table: 

18 

19 CC This rule is for a specific procedure or category as it relates to another specific 

20 procedure or category for any ICD code associated with the Index code. 
21 

22 CS This is for a specific procedure or category as it relates to a specific ICD code 

23 associated with the Index code. 

24 • The rule identifier is an assigned mnemonic based on what the rule is to achieve. 

25 • The Logical indicates if the rule is positive or negative (inclusionary or 

26 exclusionary) 

27 • The Number Required is a count of the number of occurrences required for the 

28 rule to be valid. 
29 

30 
31 
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1 

2 
3 
4 



QUALIFYING INDEX TABLE 

Table houses qualifying circumstances based on presence or non- 
existence of Specific procedures and/or ICD codes that would qualify or disqualify a 
patient history in the determination of an Episode of Care. 



c 

J 


Rule Type 


Alpha/Numeric 


2 


II = Index Code specific rule 


6 








IS = specific ICD code rule 


7 








IC = multiple ICD to category rule 


8 
9 








IA = ICD to age rule 








EG = ICD to gender 




A InVi a /Mi l m pri c 


4 


assigned from Oualifvine Master Table 


10 


Tnflifntrir 
lilLLlVuLUl 


A lnnji/MnrnpriP 

i\.llJllCU 1 1 UUld IV/ 


2 


T = TnHpx coHp 


1 1 








R = Related 


1 0 
1Z 








S = signs/symptoms 


13 








RO = Rule out 
M = Miscoded 


14 








V = Vcodes 


15 








MI = Miscoded Index 


16 








or Blank 


17 


Code 


Alpha/Numeric 


5 


category, CPT, HCPCS, ICD or blank 


18 


Update 


Character 


1 


A, C, or Blank 


19 


Total 




14 





20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



USE: 



To act as a qualifying mechanism for determining if claims information can be 
used in the assignment of an EOC 
This table interrelates with: 

- Procedure Table 

- Category Table 

- Qualifying Group Table 

- ICD Description Table 

- Index Detail Table 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



QUALIFYING CODE TABLE 

Table houses qualifying circumstances based on the presence or non- 
existence of a specific combination of procedure codes that would qualify or disqualify 
a patient history in the determination of an Episode of Care. 



Rule Type 


Alpha/Numeric 


2 


CC = Multiple code rule 
CS = code specific rule 


Rule Identifier 


Alpha/Numeric 


4 


As labeled in Qualifying Master Table 


Primary code 


Alpha/Numeric 


5 


CPT, HCPCS or category or ICD 


Secondary Code 


Alpha/Numeric 


5 


CPT, HCPCS or category or ICD 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



14 



To act as a qualifying mechanism for determining if claims information can be 
used in the assignment of an EOC. 
This table interrelates with: 

- Procedure Table 

- Category Table 

- Qualifying Group Table 

SPECIALTY TABLE 



Table provides a listing of medical specialties with an assigned numeric 



identifier. 



Specialty (Key) 


Alpha/Numeric 


3 


Medicare specialty indicator 


Beg-CPT 


Alpha/Numeric 


5 


Beginning CPT to include 


End-CPT 


Alpha/Numeric 


5 


Ending CPT to include 


Update 


Character 


1 


A, C. or Blank 



Total 14 
USE: 

This table is used to specify which Specialty is most commonly used 
with which CPT. 

A description of the specialty will be in the documentation. 
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1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



ZIP/REGION TABLE 

Table provides a listing of geographical zip codes sorted into 10 regional 
zones, standard HCFA information. 



Region Indicator 


Alpha/Numeric 


2 


Medicares Ten Regions 


Beg-Zip Code 


Numeric 


5 


Beginning Zip Code Range 


Beg-Zip Code 


Numeric 


5 


Ending Zip Code Range 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 

statistic table. 
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This table is used to specify which Medicare Region to use for the 



SPECIALTY STATISTIC TABLE 

Table provides a listing of medical specialties with an assigned numeric 



identifier. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Specialty 


Alpha/Numeric 


3 




Beg-CPT Code 


Alpha/Numeric 


5 


Beginning Range (Service Area) 


Beg-CPT Code 


Alpha/Numeric 


5 


Ending Range (Service Area) 


Category 


Alpha/Numeric 


4 


Mnemonic 


Multiplier 


Numeric 


6 


Implied decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 
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This table is a matrix that is directly tied to the parameter table by the 
index code. Its purpose is to give a numeric multiplier that is applied to the occurrence 
field in the parameter table, to vary the parameter by service area and/or sex and/or 
region, (i.e., if the occurrence is 2 and the multiplier for a specialist is 1 .5, the specialist 
may receive a total of 3.) Multiple multipliers may be applicable to each parameter. 



1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 



AGE/GENDER STATISTIC TABLE 

Table provides a listing of each CPT code for an index code with a 
numerical factor used to adjust the frequency of each code by age and/or gender specific 
data analysis. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Age 


Alpha/Numeric 


2 


00-99 


Sex 


Alpha/Numeric 


1 


M } F or Blank 


Category 


Alpha/Numeric 


3 


Mnemonic 


Multiplier 


Decimal 


6 


Implied decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 
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This table is a matrix that is directly tied to the parameter table by the 
index code. Its purpose is to give a numeric multiplier that is applied to the occurrence 
field in the parameter table, to vary the parameter by service area and/or sex and/or 
region, (i.e. if the occurrence is 2 and the multiplier for a male is 1.5, the male may 
receive a total of 3.) Multiple multipliers may be applicable to each parameter. 

REGION STATISTIC TABLE 

Table provides a listing of CPT codes for an index code with a numerical 
factor used to adjust the frequency of each code by regional data analysis. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Region 


Alpha/Numeric 


2 


Medicares Ten Regions 


Multiplier 


Decimal 


6 


Implied decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 
USE: 



14 



This table is a matrix that is directly tied to the parameter table by the 
index code. Its purpose is to give a numeric multiplier that is applied to the occurrence 
field in the parameter table, to vary the parameter by service area and/or sex and/or 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 



region, (i.e., if the occurrence is 2 and the multiplier for a region is 1 .5, the region may 
receive a total of 3.) Multiple multipliers may be applicable to each parameter. 

FILE LAYOUT FOR CLAIMS DATA CONTRIBUTION 

We prefer Electronic Media Claims National Standard Format; however, 
if you are not using EMC the following is our suggested layout. Please include an exact 
layout of the format you use with your submission. The record layout that follows is for 
each line item that appears on a claim. The charge (field 19) should be the non- 
discounted fee-for service . There should be no aggregation or fragmentation. 



Field 



Alpha/ 



12 


Number 


Description 


Length 


Numeric 


Comments 


1 ^ 


1. 


Rendering Provider ID 


15 


A/N 


Unique provider identification number or 










SSN 


14 


2. 


Billing Provider ID 


15 


A/N 


Unique provider identification number or 


15 










SSN 


16 


3. 


Provider Specialty 


3 


A/N 


Supply a List of Specialty codes used 


17 


4. 


Patient ID 


17 


A/N 


Unique patient ID number or SSN. May be an 


18 










encrypted or encoded format. 


5. 


DOB 


6 


N 


Patient Date of Birth MMDDYY 


19 


6. 


Sex 


1 


A 


M = Male, F = Female 


20 


7. 


Subscriber ID 


25 


A/N 


Insured's I.D, No., Normally SSN 


21 


8. 


Relationship 


1 


N 


Patient to Subscriber, 1 = Self, 2 = Spouse, 3 


22 










= Dependent 


23 


9. 


Bill ID 


15 


A/N 


Unique claim/bill identification number 


10. 


From Date of Service 


6 


N 


MMDDYY 


24 


11. 


To Date of Service 


6 


N 


MMDDYY 


25 


12. 


Provider Zip 


5 


N 


Standard 5 digit Zip Code 


26 


13. 


Place of Service 


2 


A/N 


Supply a list of POS codes used 


27 


14. 


Type of Service 


2 


A/N 


Supply a list of TOS codes used 


28 


15. 


Procedure Code 


5 


N 


Submitted CPT or HCPC code 


16. 


Modifier 


2 


N 


Submitted CPT modifier 


29 


17. 


2nd Modifier 


2 


N 


If multiple modifiers are submitted, show the 



30 
31 



second modifier used. Anesthesia Modifiers 
(P1-P6) 
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1 18. Claim type 3 A/N Payor Class Code-W/C, HCFA, Medicaid etc. 

2 19. Charge 5 N Billed amount, right justified, whole dollars 
^ 20. Allowed Amount 5 N Right justified, whole dollars 

21. # of days/units 5 N number of days and/or units 

4 

22. Anesthesia time 3 N Actual Minutes 

5 23. ICD1 5 A/N First diagnostic code attached to procedure 

6 24. ICD2 5 A/N Second diagnostic code attached to procedure 
j (Both ICD1 & ICD2 are left justified, 

assumed decimal after 3rd byte) 

8 

25. ICD3 5 A/N Third diagnostic code attached to procedure 

Q 

26. ICD4 5 A/N Fourth diagnostic code attached to procedure 



10 27. Out-patient facility 5 A/N Outpatient facility/outpatient hospital 

1 1 identifier 

12 28. Revenue Code 3 N Revenue center code 

13 

ACCEPTABLE MEDIA TYPES 

14 

15 * 9 track tape: 1600 or 6250 BPI, ASCII or EBCDIC, Labeled or Unlabeled, 

Unpacked data, Fixed record lengths 

17 * Floppy disk; 3.5" (1.44Mb or 720K) or 5.25" (1.2Mb or 360K), Standard MS- 
DOS formatted disk, ASCII fixed record length or delimited file 

19 * DC 600A or DC 6150 cartridge : "TAR" or single ASCII or EBCDIC file, 

20 Unpacked data, Fixed record lengths 

21 * 8 mm Exabyte tape: "TAR" or single ASCII or EBCDIC file, Unpacked data, 

22 Fixed record lengths 

23 * 3480 cartridge: Unpacked data, Fixed record lengths, Compressed or 

24 Uncompressed 

25 * Maximum Block size 64,280 
26 

27 DATA PROCESSING METHODOLOGY 

28 This invention is a process for analyzing healthcare providers 1 billing 

29 patterns to assess utilization patterns of medical services. The method of the invention 

30 incorporates a set of statistically derived and clinically validated episode of care data to 

31 be used as a paradigm for analyzing and comparing providers' services for specific 
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1 diagnoses or medical conditions. This invention utilizes a series of processes to analyze 

2 the client's healthcare claims history to create unique parameters. In its preferred 

3 embodiment, the invention is implemented in software. The invention-provides the 

4 following functions or tools to the client: creation of local profiles, display of profiles 

5 and comparison of profiles. 

6 The creation of local profiles function gives the client the ability to 

7 develop unique episode of care profiles utilizing their own claims history data. The 

8 process for creating these profiles is identical to the process used in the development of 

9 the reference profiles. 

10 The display of profiles function provides a look-up capability for 

1 1 information stored in the reference tables or in client generated profile tables. This 

12 look-up capability may be displayed on the computer screen or viewed as a hard-copy 

13 printout. 

14 The comparison of profiles function provides a comparison between any 

15 two profile sources with attention to variance between them. Some examples include 

16 comparing client specific profiles to reference tables, comparing a specific subset of the 

17 client's data (eg, single provider) against either reference tables or the client's profiles, 

18 or comparing different subsets of the client's profiles to subsets of reference tables. 

19 There are four main processes involved in the invention, as depicted in 



20 FIG. 10. These are Read, Analyze and Merge (RAM), 1001, further depicted in FIG. 

21 11; Episode of Care analysis (EOC), 1002, further depicted in FIG. 12; Look-up 

22 function, 1003, further depicted in FIGS. 13 and 14; and Profile Comparison, 1004, 

23 further depicted in FIG. 15. The invention also includes an innovative reporting 

24 mechanism. Each of these four main processes and the reporting mechanism is 

25 described in detail in the remainder of this section. 
26 

27 A. Transforming Raw Data Into an Informative Database 

28 Both the RAM and the EOC processes involve healthcare claims history 

29 search and analysis. The intent of the RAM and the EOC claims history processing is 

30 to enable the end user to establish their own unique profiles based on their existing 

3 1 claims data information. Developing a database of historical provider billing data 
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1 which will be used to provide the functionality of the invention is the first step in the 

2 invention. 
3 

4 1. Read, Analyze and Merge ("RAM") 

5 In order to define a profile a significant quantity of historical medical 

6 provider billing information must be analyzed. As indicated above, the provider 

7 billings may come from a variety of sources, with the general guideline that accuracy 

8 and completeness of the data and a statistically significant sample of provider billings 

9 are required to develop a reliable profile. In the preferred embodiment of the invention, 

10 no less than two years of consecutive claims history are used to develop the profiles. 

1 1 The RAM process verifies existence and validity of all data elements in a claims history 

12 before the data is processed to develop a profile. The reader is directed to FIGS. 1 and 

13 6-8 for pictorial representations of the preferred embodiment of the invention. FIG. 1 

14 depicts the high level steps performed in one embodiment of the invention. The data 

15 flow shown in FIG. 1 includes loading client data 101 from tape 100, reordering various 

16 fields 103 and performing date of service expansion 104 as necessary. Next, data are 

17 merged (combined) 1-5 and sorted 106 to ensure all bill IDs are grouped together. The 

18 data 108 are then read, analyzed and merged into an extended data set (EDS) 110. 

19 Reporting and any other processing may occur 111 and an Episode of Care database 

20 1 12 is created. In the preferred embodiment of the invention, the steps of the invention 

21 are implemented in a software product referred to as Care Trends available from 

22 Medicode, Inc. of Salt Lake City, Utah. 

23 FIG. 6 depicts read, analyze and merge processing that occurs in the 

24 preferred embodiment of the invention. First, one claim at a time the data 603 are read 

25 601, crosswalked and scrubbed (filtered) 602. Then a claim is analyzed 604 with the 

26 results output to a log file 605. The results in the log file 605 are then compared 606 to 

27 the original claim data and inserted 607 into an extended data set 608. 

28 FIG. 7 depicts an analytical process of the preferred embodiment that 

29 includes initializing 701 RVU and line number for each line of the claim and sorting 

30 702 by RVU (descending) and CPT and charge in order to prepare for proper analysis 

31 by Medicode ? s Claims Edit System (CES). Then 703 line items are split into two 
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1 groupings of surgical assistant modifiers and all other modifiers in separate groups. 

2 Each of the two groups is then validated 704 against disease classification codes (ICD 

3 9); procedure edits rules 705 (CES tables) and unbundle/rebundle edits 706 are 

4 performed. 

5 FIG. 8 depicts the merge process of the preferred embodiment of the 

6 invention. It includes reading 802 each line from the log file for the current bill, 

7 proceeding with processing if the record read is pertinent 804 and determining whether 

8 to add the record to the extended data set 805-807. 

9 The following text includes a written description of the RAM processing 

10 that is performed in the preferred embodiment of the invention. FIG. 1 1 shows the 

1 1 RAM process. 

12 The first step in the RAM process is determination of a patient record, 



13 1 101 . It is necessary to establish a patient record that can be used in the episode of care 

14 extraction process (explained in detail below). In the preferred embodiment, a patient 

15 record is identified as a unique patient history involving no less than two years of 

16 sequential claims history. Because identifying patient information is often removed 

17 from patient records to ensure patient confidentiality, patient information such as 

18 subscriber/relationship, patient ID, age, gender, bill ID and claim ID may be useful in 

19 positively identifying a particular patient. It should be noted that claims history data 

20 from various sources may need to be handled differently to identify patient records due 

21 to differences in file organization and level of detail of information provided. The 

22 amount of information desired to be captured may vary in different embodiments of the 

23 invention, but generally the information to be captured is that on a standard HCFA 1500 

24 billing form, Electronic Media Claims, UB 82 or UB 92 claim forms, all of which are 

25 generally known in the industry. 



26 The next step, 1 102, is the manipulation of the client file layout to 

27 extrapolate or crosswalk the pertinent information in order to conform to the logic of the 

28 invention. Examples of this step include: translation of type of service, specialty type, 

29 modifiers, and/or place of service information. 

30 The next steps involve the validation of claims elements. Each line item 

3 1 of claims history is compared against the Procedure, Description tables, (such as CPT or 
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1 HCPCS description tables; such tables generally are referred to as Description Tables 

2 and may contain any coding schemes) and the ICD description tables to validate the 

3 codes contained in the line item, 1 103. Line items with an invalid code are not included 

4 in the remainder of RAM processing, though they are counted for future reference. 

5 Line items which indicate services being performed over a period of more than one day 

6 are expanded into numerous line items, one for each service performed, 1 104. The 

7 services are then each given a unique date of service beginning with the "date of service 

8 from" for the first line item and ending with the "date of service to" for the last line 

9 item. The last validation step, 1 105, is the conversion of old CPT codes to new CPT 

10 codes. This step is essential to provide the most accurate statistics relative to physician 

1 1 office and hospital visits (termed Evaluation and Management Services). 

12 The last step of the RAM process is to edit all claims for errors, through 

13 an appropriate claims edit tool, 1 106. In the preferred embodiment, software known as 

14 "CLAIMS EDIT SYSTEM" which is available from Medicode, Inc. located in Salt 

15 Lake City, Utah is used to detect and correct any duplicate line items or inappropriately 

16 billed services. This results in an appropriately processed set of raw data that is now in 

17 a condition for episode of care processing. The reader is directed to the RAM source 

18 code in the Microfiche Appendix for all details of this processing performed in the 

19 preferred embodiment. 

20 Figure 9 depicts episode of care formation in the preferred embodiment. 

21 This processing includes processing the records in the extended data set that relate to 

22 the current index code. This relation is determined by the index tables. Then the 

23 records are broken into potential episodes of care based on a period of time specified in 

24 a window table. Then the episode of care is qualified based on the rules in a qualifying 

25 table. Qualifying episodes of care are inserted into the episode of care table. 

26 2. Determination of Episode of Care 

27 The next step in transforming raw data into a useful database is to 

28 determine episodes of care for the data that has already undergone RAM processing. In 

29 the invention, a database is created which contains profiles for various diagnoses, 

30 chronic and otherwise, including complications indicators. Creation of the database 

3 1 depends on accurately defining an episode of care ("EOC") for each diagnosis. An 
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1 episode of care is generally considered to be all healthcare services provided to a patient 

2 for the diagnosis, treatment, and aftercare of a specific medical condition. The episode 

3 of care for a single disease is depicted in FIG. 2. In the simplicity of the figure, it can 

4 be seen that for the diagnosis in question, all healthcare services provided between onset 

5 and resolution should be incorporated into the database. An example of this would be a 

6 patient who has been afflicted with acute appendicitis. The patient's life prior to onset 

7 of the acute appendicitis would be considered a disease free state. On some date, the 

8 patient would notice symptoms of acute appendicitis (although he may not know the 

9 diagnosis) that cause him to seek the attention of a medical provider. That event would 

10 be considered the onset. During the disease state, numerous events may occur, such as 

1 1 the patient consulting a family practitioner, consulting a surgeon, laboratory work and 

12 surgical services being performed, and follow-up visits with the provider(s). When 

13 further follow-up is no longer required, resolution has been reached. Thus an episode of 

14 care has been defined and data from that patient's episode of care is used in the 

15 invention to construct a profile for the diagnosis applicable to that patient. Without the 

16 use of additional logic, however, the use of that definition of an episode of care would 

17 result in erroneous data being entered into the EOC database. 

18 For example, in FIG. 3 it can be seen that a patient suffering from a 

19 chronic disease who contracts a second disease could be treated both for the chronic 

20 disease and for the second disease during the disease state (i.e. between onset and 

2 1 resolution). If all medical provider billing data during the disease state were entered 

22 into the database, then the database would contain erroneous historical data for that 

23 individual's diagnosis. For example, if a patient who suffers from psoriasis were to be 

24 diagnosed with acute appendicitis and received treatment for psoriasis between the time 

25 of onset and resolution of his acute appendicitis, then the provider billings would 

26 contain both billings for treatment of the psoriasis and the acute appendicitis. Therefore 

27 the invention incorporates methods for discerning medical provider billings relevant to 

28 a particular diagnosis. Further, the disease state could be the active state of a chronic 

29 disease, and resolution could be the disease returning to its inactive state. A method for 

30 handling this situation is therefore also provided. 
31 
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1 Other alternatives in the course of a disease further complicate accurately 

2 defining an episode of care. From FIG. 4 it can be seen that for any particular 

3 diagnosis, the outcome could be resolution, as described above, return to the chronic 

4 state of a disease, or complication of the disease. For example, if a patient has 

5 undergone an appendectomy, the patient may contract an infection following the 

6 surgical procedure. Because complications of various types and durations and in 

7 varying frequencies are associated with various diagnoses, a method for incorporating 

8 the complication data into the statistically-derived practice parameter is intended to be 

9 provided in the invention. 



10 FIG. 5 depicts the phases of an episode of care, including the sequence 

1 1 of patient workup, treatment, and eventual solution, return to the chronic state, or 

12 complication followed by either resolution or return to the chronic state. 

13 The method for defining an entire episode of care provided in the 



14 invention is used to construct a database of EOCs based on billing data that has been 

1 5 filtered to eliminate data irrelevant to the diagnosis which would lead to an erroneous 

16 profile. Essential to the determination of an EOC are certain qualifying circumstances. 

17 These circumstances are managed through the use of interrelational qualifying tables, to 

18 provide a mechanism for sorting patient history for the occurrence of specific 

19 procedures or ICD codes that are requisite for an EOC to be valid. 



20 The steps used in the preferred embodiment to determine an episode of 

21 care are shown in FIG. 12 and as follows. 

22 a.) Data Sort by Index Code 

23 First, 1201, a temporary file is created based on combining the 



24 authorized and/or disallowed ICD codes that are associated with a given index code in 

25 the Index Global Table (listing preventative and aftercare codes) and the Index Detail 

26 tables. The temporary file is created using the Index Table, which determines whether 

27 or not the Index Detail Table only should be accessed or whether the Index Global 

28 Table is also necessary for drafting the temporary file. Second 1202, the raw data set 

29 which has undergone RAM processing is sorted by index code (i.e. general diagnosis) 

30 to find all patient records within a patient history having an occurrence of a particular 

3 1 index code. It is contemplated that the number of occurrences of a particular index code 
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1 can be defined by the user. In the present embodiment, it is recommended that the 

2 particular index code being sought occur on at least two different dates of service. The 

3 valid components of these patient records are then checked against the interrelational 

4 qualifying tables to identify ICD codes associated with the chosen index code. The 

5 qualifying circumstances identify criteria such as procedures relating to specific medical 

6 conditions which may have been indicated as usually requiring an Evaluation and 

7 Management (E/M) service during the course of treatment. For example, an occurrence 

8 of a qualifying circumstance such as an E/M service during the patient history is 

9 considered in the criteria of an episode of care. In addition, the patient records are 

10 searched for any complicating ICD codes that would disqualify the patient record for 

1 1 inclusion in the EOC (such as diabetes or renal failure). 

12 Fourth, 1203 the patient records are compared against the interrelational 

13 qualifying tables to ensure compliance with all patient-level qualifying rules. Patient 

14 records that fail to qualify are no longer considered for EOC evaluation for this Index 

15 Code, however, they may still qualify for other Index Code analysis. Fifth, 1205 all 

16 relevant line items for every remaining patient record are checked against the temporary 

17 file created in step one for complicating diagnosis codes. Any patient record thus 

18 identified with a complicating diagnosis code is removed from further EOC processing. 

1 9 b.) Determination of Clear Windows 

20 Clear window processing defines the onset and resolution points of an 

21 episode of care. The actual parameters used in clear window processing may vary in 

22 various implementations of the invention. A clear window time period is selected for 

23 the specific Index Code from the window table 1206. Next, 1207 proceeding 

24 chronologically, each record is compared with the record immediately preceding it. The 

25 first record read defines the beginning event of an initial episode of care and the last 

26 record read defines the terminating event of a final episode of care. If the two records 

27 being compared are separated by a time period equal to, or greater than, the clear 

28 window the earlier record is identified as the terminating event of the earlier episode 

29 and the later record is identified as the beginning event of the next episode. 

30 Accordingly, the initial episode of care and the final episode may be the same episode 

31 of care. It is also possible, for the first record and the last record to be the same record. 
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1 This iterative process is continued for all remaining records for all patient claims. In 

2 this fashion potential EOCs are identified within the patient claims. 

3 c.) Valid Episode of Care 

4 Each potential episode is then checked to determine if the index code in 

5 question appears on the required number of dates of service within the EOC 1208. If 

6 the index code does not appear the required number of times, the potential EOC is 

7 pended. The qualifying tables are then checked to determine if the potential EOC meets 

8 the minimum criteria for procedure codes (such as surgical services) that are expected 

9 to be found within a potential episode of care for a given index code. If the minimum 

10 criteria are not found in an episode of care, it will not be considered in the profile 

1 1 summary. Processing continues for all patient records. Once an EOC has been 

12 determined for a set of claims history meeting the criteria for an Index code, a profile is 

13 assigned to the EOC based upon different combinations of treatment patterns that are 

14 likely to arise for a given medical condition, 1209. There are eight basic profile classes 

15 which outline the common combinations of treatment patterns to statistically analyze 

16 and store. These Profile Classes are: 



17 0. Common Profile (diagnostic and E/M services common to all of the 

18 above). 

19 1 . Surgery/Medicine/Radiation Profile 

20 2. Medicine/Radiation Profile 

21 3 . Surgery/Radiation Profile 

22 4. Surgery/Medicine Profile 

23 5. Radiation Profile 

24 6. Medicine Profile 

25 7. Surgery Profile 

26 8. Summary Profile (summary of 0-7 above) 

27 After all valid EOCs have been assigned to a unique profile processing 

28 continues with population of the procedure and category tables. 

29 d.) Populating the Procedure and Category Parameter Tables 

30 The data from qualified EOCs will be added to the procedure and 

3 1 category parameter tables 1210. Data from all of the episodes of care for each index 
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1 code are inserted into the parameter tables to create the summary statistical profiles. In 

2 the preferred embodiment these tables are accessed by index code and populated with 

3 data from all the episodes of care for each index code to create and provide summary 

4 statistics. The procedure description table and category table are also accessed to 

5 determine a description of the procedure codes and the service category in which they 

6 fall. 



7 The final step of the EOC process is the generation of output reports, 

8 1211. The output report of this step can be either an online look-up report or a hard 

9 copy report. Reports are further described below. 

10 The reader is directed to the Microfiche Appendix containing the source 

1 1 code for EOC processing and to FIG. 9 for supplementary information. 

12 B. Use of the Database 

13 1. Look-up Function 

14 In the preferred embodiment of the invention, a look-up function is 



15 provided so that various information available in the database may be accessed. In 

16 general, a specific diagnosis may be reviewed in each of the tables of the database based 

17 on ICD code. In various embodiments of the invention, other look-up functions may be 

1 8 provided based on nearly any category of information contained in the database. In the 

19 preferred embodiment of the invention display of profiles is performed as part of the 

20 look-up function. Information in the procedure and category parameter tables are 

21 displayed by index code sorted chronologically to show a profile. 



22 The specific steps of the preferred embodiment of the Look-Up function 

23 of the invention are shown in FIG. 13 and described as follows. 

24 The first step, 1301, is to review the reference tables for a given Index 

25 ICD code. Once a specific diagnosis is chosen for review the process moves to step 

26 two. In step two, 1302, the ICD description table is accessed to verify that the ICD-9 

27 code is valid, complete and to provide a description of the diagnosis. It will also 

28 indicate a risk adjustment factor assigned to the diagnosis. 

29 In step three, the Index tables are accessed, 1303. Next, step four, 1304, 

30 is to determine whether or not the chosen ICD code is an Index code. If it is found as 

31 an Index code, any additional ICD codes associated which the selected Index code will 
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1 be accessed, 1305. If a chosen diagnosis is not listed as an index code, a prompt, 1306, 

2 will allow a search for the selected ICD code to list which index code(s) it may be 

3 associated with and its indicator, 1307. A word search capability, 1308, is included in 

4 the look-up function applicable to the Index code display. A word or words of a 

5 diagnosis is entered and a search of possible ICD codes choices would be listed. 

6 The next step, 1309, is to access the Parameter Tables to display selected 

7 profiles. The information provided is driven by the index code and is sorted 

8 chronologically, by profile class and by category of procedures. The user is then given 

9 the opportunity to choose whether the profiles to be accessed are from the reference 

10 tables, client developed profiles, or both, 1310. Next the Procedure Description Table, 

11 1311, and the Category Table, 1 3 1 2, are accessed to ascertain description of procedure 

12 codes and categories under which they fall. 



13 The last step of the Look-Up function is the output of report product, 

14 1313. This report may either be on-line look-up process or in the hard copy report 

15 format. 

16 The preferred embodiment of the invention also performs subset profile 

17 look-up. This permits analysis of profiles based on selected subsets of data such as age, 

1 8 gender, region and provider specialty. 

19 The process for the subset of profiles look-up includes all of the steps 

20 necessary for the general profiles look-up and includes the following additional steps 

21 shown in FIG. 14 and described below. 

22 The Age/Gender Table is accessed to ascertain the standard age ranges 



23 and/or gender selection for a given profile, 1402. This information is stored by index 

24 code with an adjustment factor to be multiplied against the occurrence count of each 

25 procedure stored in the parameter table. For example, an adjustment factor of 0.6 

26 associated with an age range of 0 to 17 would be calculated against an occurrence count 

27 of 10 for CPT code 71021 for Index code 493XX giving an age adjusted occurrence of 

28 6 for that age range. 

29 The Region Statistic Table, 1403, is accessed and used in a similar 

30 manner as the Age/Gender Table. This table has adjustment factors based on ten 

31 regions throughout the United States. 
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1 The Zip/Region Table, 1404, is accessed to identify what region a 

2 particular geographic zip code falls within. 

3 The CPT Statistic Table, 1405, is accessed and used in a similar manner 

4 as the Age/Gender table. This table has adjustment factors based on different medical 

5 specialty groupings. 

6 The Specialty table, 1406, is accessed to ascertain what particular 

7 specialty groupings are suggested. 

8 The subset parameter Look-Up function also includes the capability of 

9 producing output reports, 1407. These reports can be on-line look-up process reports or 

1 0 hard-copy report format reports. 

1 1 2. Comparison Processing 

12 In the preferred embodiment of the invention, it is possible to compare 



13 profiles developed from a data set against profiles developed from a reference data set. 

14 Subsets of profiles may be compared as well. Profiles may be compared for any index 

15 code and profile reports may be output. It is also possible to identify those medical 

16 providers (whether individuals or institutions) who provide treatment that does not fall 

17 within the statistically established treatment patterns or profiles. Further, various 

18 treatment patterns for a particular diagnosis can be compared by treatment cost and 

19 patient outcome to determine the most effective treatment approach. Based on 

20 historical treatment patterns and a fee schedule, an accurate model of the cost of a 

21 specific medical episode can be created. 

22 The specific process of Comparison Processing is shown in FIG. 15 and 

23 described as follows. The first step, 1501, is the comparison of information developed 

24 from the data history search process with reference information stored in the Parameter 

25 Tables. The next step, 1502, is to test the services from the history processing to see if 

26 it falls within the defined statistical criteria in the Parameter Tables. If it does an 

27 indicator is given to this effect, 1504. If the services fall outside the statistical criteria of 

28 the reference Parameters Table, a variance alert describing the difference will be given, 

29 1503. The process may be repeated for each index code and its profile developed in the 

30 history process, 1505. The final step is to produce output reports, 1506. These reports 

3 1 are either on-line look-up process reports or hard-copy report format reports. 
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1 3. Reporting 

2 Reporting of various information contained in the database is provided in 

3 the preferred embodiment. Six different types of reports or displays are provided in the 

4 preferred embodiment, these are: Provider Practice Profile Report, Profile Comparison 

5 Reports, Resident Parameters Display, Local Parameters Display, Parameter 

6 Comparison Report and Chronological Forecast. Each of these reports or displays is 

7 described as follows. 

8 The Provider Practice Profile Report is a set of reports which provide a 

9 tally or summary of total CPT and/or ICD code utilization by a provider or group of 

10 providers during a specified time interval and allows comparison against provided 

1 1 reference data or client generated reference data. 

12 The select criteria for running the tally can be any one of the following: 

13 - single physician, department, specialty or clinic by CPT and/or ICD 

14 - multiple physicians, departments, specialties, or clinics by specialty, 

1 5 region, CPT and/or ICD 

16 - period of time being analyzed 

17 Included in the report is the following: 

18 - criteria for select 

19 - claims analyzed 

20 - average lines per bill 

21 - invalid CPTs and percent of total for study 

22 - invalid ICDs and percent of total for study 

23 - incomplete ICDs and percent of total for study 

24 - patients in age categories 

25 - patients by gender 

26 - missing ICDs and percent of total for study 

27 The report includes numerous (up to about 22 in the preferred 

28 embodiment) separate procedure (such as CPT) categories which are headers for each 

29 page. Each CPT utilized within that category will be reported by: 

30 - frequency and percent of total 
31 
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1 - dollar impact and percent of total for single or multiple fee schedules 

2 and/or allowable reimbursement schedules 

3 - grand total if more than a single physician report 

4 The report includes a tally by ICD. Each ICD utilized is reported on by: 

5 - frequency and percent of total 

6 - dollar impact and percent of total for single or multiple fee schedule 

7 and/or allowable reimbursement schedules (dollar impact based on 

8 each line item CPT correlated to the ICD) 

9 If a report includes region and/or specialty, there are numerous tallies for 

10 procedure categories and/or ICD. 

1 1 The Profile Comparison Reports give the client a comparison of a health 

12 care provider's (or group of providers') utilization of CPT and/or ICD-9 codes in a 

13 specific episode of care against a reference set of utilization profiles. This includes 

14 number, frequency and chronological order of services along with other statistical 

15 information (eg, range, mode, confidence interval, etc.). 

16 The comparison can be against one of the following: 

17 - national norms resident in the tables 

18 - regional norms resident in the tables 

19 - client established norms developed by use of the tally report, outlined 

20 above 

21 - other 

22 Selection criteria include the following: 

23 - single physician, department, clinic or specialty by CPT and/or ICD 

24 to be compared against national, regional, specialty, and/or client 

25 established norms 

26 - multiple physicians, departments, clinics, or specialties by CPT 

27 and/or ICD by specialty and/or region, to be compared against 

28 national, region, specialty, and/or client established norms 

29 - set period of time being analyzed 

30 General information included in the report includes: 
31 
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1 - criteria for select (i.e., national, regional, specialty, and/or client 

2 established) 

3 - claims analyzed 

4 - average lines per bill 

5 - invalid CPTs and percent of total for study and comparison 

6 - invalid ICDs and percent of total for study and comparison 

7 - incomplete ICDs and percent of total for study and comparison 

8 - patients in age categories and comparison 

9 - patients by gender and comparison 

10 - missing ICDs and percent of total for study and comparison 

1 1 The report includes numerous separate CPT categories which are headers 

12 for each page. Each CPT utilized within that category will be reported by: 

1 3 - frequency and percent of total 

14 - dollar impact and percent of total for single or multiple fee schedules 

1 5 and/or allowable reimbursement schedules 

16 - grand total if more than a single physician report 

17 The report includes a tally by ICD. Each ICD utilized is reported on by: 

18 - frequency and percent of total 

19 - dollar impact and percent of total for single or multiple fee schedule 

20 and/or allowable reimbursement schedules (dollar impact based on 

21 each line item CPT correlated to the ICD) 

22 If a report includes region and/or specialty, there are numerous tallies for 

23 CPT categories and/or ICD. 

24 The Resident Parameters Display provides the client a look-up mode for 

25 information stored in the Practice Parameter Tables or client generated parameter tables. 

26 This lookup should be on the computer screen or as a print out. 

27 The selection criteria is based on the key elements of the Practice 

28 Parameter tables. For Example: 

29 - Index code for associated CPT codes and/or any other the following: 

30 - index code only 
31 



43 




1 - index code and indicators (i.e, related, complicating, rule/outs, 

2 symptoms, etc) 

3 - specialty 

4 - region 

5 - age 

6 - gender 

7 - standard length of Episode of Care 

8 - based on profile (tally) 

9 - based on parameter (timeline) 

10 - regional variables 

11 - other misc. look-ups 

12 - geozips incorporated in a region 

13 - CPT for follow up days and/or lifetime occurrence 

14 - specialty and associated CPT codes 

15 - ICD and Risk Factor 

16 The Local Parameters Display provides the same information as 

17 described in the Display of Resident Parameters listed above. 

18 The Parameter Comparison Reports are a set of reports which give the 

19 client a comparison of a physician (or group of physicians) utilization of CPT and/or 

20 ICD against an existing set of utilization norms over a timeline and in chronological 

21 order. 

22 The comparison can be against one of the following: 

23 - national norms resident in the tables 

24 - regional norms resident in the tables 

25 - client established norms developed by use of the tally report, outlined 

26 above 

27 - other 

28 Selection criteria include the following: 

29 - single physician, department, clinic or specialty by CPT and/or ICD 

30 to be compared against national, regional, specialty, and/or client 

3 1 established norms 
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1 - multiple physicians, departments, clinics, or specialties by CPT 

2 and/or ICD by specialty and/or region, to be compared against 

3 national, region, specialty, and/or client established norms 

4 - set period of time being analyzed 

5 General information included in the report includes: 

6 - criteria for select (i.e, national, regional, specialty, and/or client 

7 established) 

8 - claims analyzed 

9 - average lines per bill 

10 - invalid claims due to incomplete Episode of Care 

11 - invalid CPTs and percent of total for study and comparison 

12 - invalid ICDs and percent of total for study and comparison 

13 - incomplete ICDs and percent of total for study and comparison 

14 - patients in age categories and comparison 

1 5 - patients by gender and comparison 

16 - missing ICDs and percent of total for study and comparison 

17 The report includes numerous separate procedure categories which are 

1 8 headers for each page. Each procedure category utilized within that category will be 

19 reported by: 

20 - frequency and percent of total 

21 - dollar impact and percent of total for single or multiple fee schedules 

22 and/or allowable reimbursement schedules 

23 - grand total if more than a single physician report 

24 The Chronological Forecast provides statistical trend analysis and 



25 tracking of the utilization of billing codes representative of services performed by a 

26 physician for a given diagnosis over a set period of time and stored in chronological 

27 order. It will provide a summation of billed codes representative of services and 

28 diagnoses utilized by an entity over a period of time. 

29 C. System Requirements 

30 The method and system of this invention may be implemented in 

3 1 conjunction with a general purpose or a special purpose computer system. The 



45 




1 computer system used will typically have a central processing unit, dynamic memory, 

2 static memory, mass storage, a command input mechanism (such as a keyboard), a 

3 display mechanism (such as a monitor), and an output device (such as a printer). 

4 Variations of such a computer system could be used as well. The computer system 

5 could be a personal computer, a minicomputer, a mainframe or otherwise. The 

6 computer system will typically run an operating system and a program capable of 

7 performing the method of the invention. The database will typically be stored on mass 

8 storage (such as a hard disk, CD-ROM, worm drive or otherwise). The method of the 

9 invention may be implemented in a variety of programming languages such as COBOL, 

10 RPG, C, FORTRAN, PASCAL or any other suitable programming language. The 

1 1 computer system may be part of a local area network and/or part of a wide area 

12 network. 

13 Referring to Fig. 16 of the drawings and to the Microfiche Appendix, there is 

14 illustrated a second embodiment of a method for implementing the present invention for 

15 determining episodes of care for a selected medical condition identified by an Index 

16 Code. This embodiment is essentially the same as that described above except where 

17 noted, and the same nomenclature and tables will be referred to as in the above 

1 8 embodiment. The method is implemented by the computer program module 

19 pp_comp.4gl, which appears in the Microfiche Appendix. 

20 a) Create Temporary File of ICD-9 Codes Corresponding to Selected Index Code 

21 First, at step 1610, a temporary file, tmpindex, is created as a programming 

22 convenience, based on the Index Code for which episodes of care are being built. An 

23 Index Code identifies a medical condition (e.g., 174? might be the Index Code for the 

24 disease, Malignant Neoplasm of Female Breast). In the Index Detail Table, each Index 

25 Code is associated with ranges of ICD-9 diagnosis codes relevant to the medical 

26 condition, as well as separate Indicator values associated with each range. Only ICD-9 

27 codes with an Indicator value of "I" or "MI" for the associated Index Code are used to 

28 drive the creation of an episode of care. 

29 At 1610, the ppjcompAgl module, after defining program variables, executes 

30 the function, lMake_index, which builds the temporary file, tmp_index, that contains a 

31 separate record for each ICD-9 code in the ranges of ICD-9 codes associated with the 
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selected Index Code. (The value of the selected Index Code is passed to lMake_index 
in the variable ir. index, which contains the Index Code value provided in the input 
record for pp_comp.4gl, e.g., index_detail. index) The function call to the IMakeindex 
appears at the bottom of page 2 of the pp_comp.4gI program listing. 

The IMake index function creates the tmp_index file by extracting from the 
Index Detail table and the Index Global table information that includes the ranges of 
ICD-9 codes associated with the selected Index Code and the Indicator value for each of 
such ICD-9 codes. For example, if, in the Index Detail table, Index Code 174? were 
associated with the following ranges of ICD-9 codes and Indicator values: 1740 to 1749 
for Indicator "I"; 174 for Indicator "MI"; 61 172 (Lump Or Mass In Breast) for Indicator 
"R;" then the tmp index file records correlating to Index Code 174? would include the 
following information: 



Indicator 


ICD9 




1740 




1741 




1742 




1743 




1744 




1745 




1746 




1747 




1748 




1749 


MI 


174 


R 


61172 



a) Find Patients With Driving ICD-9 Codes 

Second, at step 1620, the raw data set that has undergone RAM processing is 
sorted by ICD-9 code to find all patient records having an occurrence of ICD-9 codes 
that may drive the creation of an episode of care for the selected Index Code (i.e., ICD- 
9 codes corresponding to ICD-9 codes in the tmpindex file having an Indicator value 
of"!" or "MI"). More specifically, the pp_comp.4gl module first creates a second 
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1 temporary file, tmp jatient, with the following statement appearing at the top of page 

2 3 of the source code listing. 

3 select unique patient, relationship, sex 

^ from e_line Ix, e_claim cx, tmp index ix 

5 

where ix.e claim id = cx.e_claim_id and 

6 

j IxJcdl = ix.icd9 and 

8 ixAndicator in ("I", "MI") and 

9 cx.e claim id I- 0 

10 

into temp tmp _patient 

11 

12 

13 This statement creates the temporary table, tmp jatient, and populates it with 

14 every unique combination of patient, relationship, and sex for every patient record 

15 containing an ICD-9 code listed in the tmp_index table with an Indicator value of "I", 

16 or "MI". Since tmp_index table maps Index Codes (medical conditions) to individual 

17 ICD-9 codes, the tmp_patient table identifies only those patients whose diagnoses in 
lg their medical claims history include one of the driving ICD-9 codes for the medical 

1 9 condition in question. 

20 The program then creates a third temporary file, tempdata, and populates it 

2\ with every record from the RAM-processed data set that meets two criteria: 

22 (1) contains a combination of patient, relationship, and sex values that 

corresponds with a record in the tmp_patient table; and 

23 

24 (2) contains an ICD-9 code that corresponds to an ICD-9 code in the tmp_index 

table. 

25 
26 
27 
28 
29 
30 
31 



The program statement that implements these two steps appears in the top half 
of page 3 of the ppjcompAgl program listing in the select statement beginning "select 
ex.*, ix.date_of_serv, ..." and ending with "into temp temp_data" Specifically, the 
following segment of the select statement links the exclaim table, which contains one 
record for each medical claim identified in the RAM-processed data set, to the 
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1 tmp jatient table described above by matching the patient ID number, relationship 

2 code, and gender values in the two tables. 

3 from eline be, e claim cx, tmpindex ix, imp jpatient ip 

^ where be. e_ claim_d=cx. e_ claim _ id and 

5 

IxJcdl = ixJcd9 and 

6 

j cx.patient - ip.patient and 

8 cx.relationship - ip.relationship and 

9 ex. sex = ip.sex and 
10 

11 

12 

13 Next, the following segment of the select statement links the e_line table, which 

14 contains all records in the RAM-processed data set (that is, each claim line item that 

15 appears in the patients' medical histories), to the tmp_index table described above by 
15 matching the ICD-9 diagnosis codes in the two tables. 

17 from e_line be, e_claim cx> tmp index ix, tmp jpatient ip 

I g where Ix. e_ claim_d=cx. e_ claim_ id and 

1 9 IxJcdl = ixAcd9 and 

20 

2\ The result of the foregoing two steps is that the temp_data table will hold data 

22 that meet the following criteria: 

23 1 . The claim line items belong to a patient who had an "I" or "MI" 

24 somewhere in their medical history. 

25 2. The claim line item includes an ICD-9 code that is also found in the 

26 temp_index table. 

27 At this point, the temp_data table holds claim line items that potentially will be 

28 included in an Episode of Care (EOC) for a selected Index Code. 

29 a) Create Procedure Categorization Table 

30 At 1630, the program creates another temporary table, cat_file that is used for 

3 1 grouping procedure codes into categories, which are described above in relation to the 
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1 Category Table. The categories represent broad classes of treatment or service types, 

2 such as Major E and M (Evaluation and Management), Minor E and M, Major 

3 Diagnostic Radiology, Minor Diagnostic Radiology, Major Laboratory, and Major 

4 Therapeutic Surgery. Categories are used in place of individual procedure codes in 

5 subsequent program steps. For example, certain qualifying rules reference category 

6 codes rather than individual procedure codes. Also, categories are used to sort episodes 

7 of care into profile classes for analysis and reporting purposes. 

8 At step 1630, the program assigns a category mnemonic (e.g., E t for Major E 

9 and M) to each procedure code found in the temp_data file. This program step is 

10 implemented by the source code at pages 3-4, beginning with the statement "call 

1 1 errorlog ("Making Cat File")," through the statement, "create unique index i catfl 

12 on catfile(proc);". Specifically, the cat_file table is built by looping through each 

13 procedure code in the temp_data table, finding every unique CPT/HCPCS code in that 

14 table and associating the code found with a category. 

1 5 b) Check Patient History Against Qualifying Rules 

16 At step 1640, the records from the patient histories (now in the temp_data 

17 table) are reviewed to ensure compliance with the patient-level qualifying rules defined 

18 by the various qualifying tables of the present invention. Patient records that fail to 

19 qualify are no longer considered for EOC evaluation for the selected Index Code. The 

20 ppcompAgl source code for implementing this step includes the statements beginning 

21 at the middle of page 4 with "declare upat_curs cursor for" and continuing through 

22 the bottom of page 5, "execute del_qual." Pertinent portions of these statements are 

23 reproduced below. 

24 foreach upatjcurs into q. * 
25 

26 

call qual check("P") returning passed, eoc jrofile, ruleerr 

27 

2g if not passed then 

29 

30 execute del_temp_data using prev _pat, prev_rel f prev_sex 

31 
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1 end foreach 

2 



3 Generally, these program statements perform the following steps: 



• read fields from each patient record in the temp_data table into upat_curs\ 

• for each patient record in upatjcurs; 

> read the record into the variable set q. *; 

> call qualjcheck function to determine if the patient data on the record 
satisfies a set of patient qualifying rules, and 

> if not, remove all of the patient's data from further consideration for the 
selected Index Code. 

These patient qualification steps are repeated until such processing has been 
completed for all patients having a record in the temp_data table. 



4 

5 

6 

7 

8 

9 
10 
11 
12 
13 

14 TheQual Check Function 

15 

16 The qualcheck function identified above can be found beginning on page 13 of 

17 the ppjcompAgl program listing, beginning with the statement "function 

18 qualcheck(inscope)" and continuing through the end of page 16. For the selected 

19 Index Code, the qual_check function loops through all entries in the qual_master 

20 (Qualifying Master) table where the Scope field is equal to the value passed to the 

21 qual_check function in the in scope variable. (In the present embodiment, the in_scope 

22 variable is set to either the value "E" or "P", which indicates whether the function 

23 checks for 'E'pisode or 'P'atient level qualifying rules.) Here, at step 1640, the value of 

24 the in_scope variable is set to T,' such that only patient level qualifying rules are 

25 executed. 

26 Based on the value of the Group field in the Qualifying Master table for the 

27 selected Index Code, the qual check function extracts qualifying rules information (i.e., 

28 Rule Type and Rule Identifier) from the qual_group (Qualifying Group) table. More 

29 particularly, when the qual_check function reads a record from the qual_master table 

30 for the selected Index Code, it uses the value of the rule_group field from the 

3 1 qualmaster record as a parameter to a query for reading a record in the qualgroup 
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1 (Qualifying Group) table. Depending upon the value of the rule type field this 

2 qual__group table record, the qual check function executes a different set of program 

3 statements implementing qualifying logic. As will be set forth more fully below, the 

4 qual_check function uses this rulejype value to extract information for identifying the 

5 proper qualifying rules from either the Qualifying Index table or Qualifying Code table, 

6 identified in the program listing as qual_ic and qual_cc, respectively. 

7 In the preferred embodiment described herein, the three values of the rulejype 

8 field that trigger execution of qualifying logic are "11", "IC", and "CC". "IF'-type rules 

9 are qualifying rules specific to the Index Code and, for example, may require two or 

10 more occurrences of the Index Code in a patient history with different dates of service. 

1 1 "IC"-type rules define criteria for Index Codes relative to procedure (CPT) category 

12 codes. An "IC"-type rule identify CPT categories (not specific CPT codes) for the 

13 specific Index Code. "CC"-type qualifying rules are similar to "IC" rules, but instead of 

14 checking for a certain number of one type of procedure category, the "CC"-type logic 

15 checks for a single occurrence of each of two separate procedure categories. 

16 Pertinent portions of the qual_check function are reproduced below. 

17 open mast_curs using in_scope 

* ^ fetch mastcurs into qm. * 

19 

let hold status = status 

20 

2 j while hold status != notfound 

22 open grp_crs using qm.rule group 

23 fetch grpjcurs into qg. * 
24 

while status /= notfound 

25 
26 

27 when qg.rule type = "H" 



28 
29 
30 
31 



when qg.rule_type~ y9 IC r 
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1 when qg.rule_type="CC" 

2 



3 
4 
5 
6 
7 
8 
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10 
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Thus, depending on the value of the rulejype field, the program applies one of 
the sets of qualifying logic to determine whether a patient's record satisfies the 
appropriate set of qualifying rules for that patient. 

Type II Qualifying Rules 

The program logic for Type II qualifying rules begins by building a SQL query 
to check the patient record for a certain number of occurrences of specific codes (ICD- 
9, CPT, HPCPS or category) or Indicator values. The requisite number of occurrences 
of codes or Indicator values for the particular rule type is stored in the Number required 
field (qg.numjequired) of the Qualifying Group table. Upon execution of the query, 
and if the requisite number of occurrences is found, the qual_check considers the 
patient to have successfully passed the Type II qualifying rules. 

More particularly, the Type II program logic builds a SQL query based on 
values read from the qual_ic table using the values of rulejype and rulejd read from 
the qualgroup table. If the cat_cpt field of the qual ic record is populated (with a 
category, CPT, HCPCS, or ICD value), the where clause of the SQL statement is 
expanded to create a statement that checks for a match between the icdl field (from the 
tmp_index table) and the value of cat_cpt. If cat_cpt is not populated, the where 
clause looks for a match between the indicator field in the tmp_index table and the 
value read from the indicator field in the qual_ic table. This process continues for 
every record in the qual_ic table containing the rulejype value read from the 
qual group table. 

When no more records exist in the qual_ic table for the given rulejype, the 
SQL statement that was constructed is executed, and the number of records returned is 
tallied. The total number of records satisfying the SQL query is then compared against 
the value of the numjequired field from the qual_group table. If the total exceeds the 



53 



1 value of the numrequired field, the rule is identified as having "passed"; if not, the rule 

2 is "failed". 

3 Next, the logical field from qual_group table is read. The logical field 

4 indicates whether the qualifying rule is inclusive or exclusive in nature. If the value of 

5 the logical field is "F'\ the rule _passed variable is inverted (that is, if the rule is 

6 exclusionary, and the requisite number of occurrences have been found, then rule was 

7 not "passed," and vice versa). Once this step is complete, the qual check function 

8 checks the rule _passed value to determine whether to continue checking the patients' 

9 records for qualifying circumstances, or stop processing the patients' records and return 

10 control to the main program ppcompAgL If the value of rule _passed for the patient's 

1 1 record is not "true", the qual_check program exits and returns the rule _passed value 

12 back to the section of pp_comp.4gl code that called this qualifying logic. 



13 
14 
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16 
17 
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Type IC Qualifying Logic 

Similar to the Type II qualifying logic, the Type IC logic initially reads a record 
from the qual_ic table using the rulejype and rule id values previously retrieved from 
the qual_group table. For each relevant record in the qual_ic table, the program counts 
the number of records in the temp_qual table where the category field matches the 
cat_cpt field value found on the qualic record. This count is then compared against 
the numjrequired field value from qual_group. If the count is greater than or equal to 
num_required, the Type IC logic sets the rule ^passed variable to "true" (and, as was set 
forth above for the Type II logic, inverts its value where the value of the logical field is 
"F"). The qual_check function then checks the rule _passed value to determine whether 
to continue checking the patients' records for qualifying circumstances. If the value of 
rule ^passed for patient's record is not "true", the qualjcheck program exits and the 
rule _passed value is returned the main program. 



28 Type CC Qualifying Logic 

29 



The Type CC qualifying logic differs from the Type II and IC logic in that it 



obtains its qualifying rule information from the qualcc (Qualifying Code) table rather 
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1 than qual_ic (Qualifying Index) table. For each record in qual_cc matching the 

2 rulejype and rulejd from qualgroup the following steps occurs: 

3 1 . The number of records in temp_qual where the category field matches the value in 

^ the cat_cptl field from qual_cc is tallied. 
5 

g 2. If this count is greater than or equal to 1, the number of records in temp_qual where 

7 the category field matches the value in the cat_cpt2 field from qual_cc is tallied. If 

8 it is not, the Type CC code skips to the logic segment in step 4 (below). 
9 

10 3. If the count is less than the value of the num required field from qual_group, the 

1 1 logical field from qualgroup is checked, and if the value of logical is "T", the 

12 passed variable is set to "false". The passed variable is also set to "false" if the 
count is not less than the value of the numrequired field and the value of logical is 
"F." (If the count is not less than num required, the code skips to the logic in step 



13 
14 
15 

16 4.) 
17 
18 
19 

20 another relevant record in the qual_cc table 

21 
22 
23 

24 value of the passed variable to the main program (as in the Type II and Type IC 

25 logic segments). 



26 
27 
28 
29 
30 
31 



4. If the passed variable is false, the section of code exits and passes control back to 
the area of the program that called this logic; otherwise the program checks for 



5. When no more relevant records exist in qual_cc, this section of code exits and 
returns control back to the area of the program that called this logic, returning the 



In each of the aforementioned qualifying logic segments, the qual check 
function evaluates whether the qualifying logic is considered "passed" or "failed." If 
the rule is considered "failed," then the records for the patient currently being processed 
have been disqualified for further processing for the selected Index Code. The function 
continues processing with the next patient. When no more patients remain, the 
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1 qualjcheck function returns control back to the main body of the pp_comp.4gl 

2 program. 

3 a) Categorize Procedure Codes in Patient History 

4 Additionally, at 1645 , as part of the foreach loop that calls the qual_check 

5 function, the program executes the following two statements appearing at the bottom of 

6 page 4 and continuing to page 5, which determine categories for the procedures codes 

7 appearing in each patient record and append a category code to the patient record: 

8 open getcat using q.cpt 

Q 

fetch get cat into q.category 

10 

The category codes are used by the qual_check function as part of qualifying 



patients for episode of care creation, at 1640, and sorting episodes of care into profile 

13 

classes, at 1680. 

14 

b) Use Clear Window To Identify Episodes of Care 

15 

After processing each patient history against the applicable qualifying rules, the 

16 

program, at step 1650 , begins to build episodes of care for patient histories that did not 

17 

fail the qualifying rules. A clear window time period delimits the onset and resolution 

18 

of an episode of care. The clear window time period is selected for a specific Index 

19 

Code from the Window Table. 

20 

In the ppjcompAgl program, the function call on page 6 to report redit begins 

21 

clear window processing. 

22 

finish report redit 

24 



25 The report rjedit function (appearing on pages 8 and 9 and reproduced in 

26 pertinent part below) identifies the proper clear window time period, flags (for later 

27 processing) records indicating a medical complication, and then applies the clear 

28 window period to identify discrete episodes of care. 

29 report r edit (c, /, /, curby) 

30 output 
31 
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order by cpatient, c. relationship, a sex, l.date_of_serv 



3 
4 
5 



select beg_win into winjtnax 
from window 

6 where staging in 

7 (select staging from index where index = 
irAndex) 

9 

10 

1 1 First, report redit function sorts the claim line item records by patient, 

12 relationship, sex and date of service. The report r edit function then determines the 
12 proper clear window period for the selected Index Code (which index corresponds to 

14 the ICD-9 codes appearing in the line item records now being processed). The beg_win 

15 (Beginning Window) field of the window (Window) table defines the clear window 
15 period, win max, that is, the maximum number of days without the occurrence of a 

U service relating to a given medical condition (Index Code) that defines the beginning of 

18 a new episode of care. The report rjedit function identifies the appropriate record in 

19 the Window Table from which to extract the Beginning Window value by matching the 

20 Staging values in the Index Table record for the selected Index Code with the Staging 

21 Indicator in the Window Table record for the selected Index Code. In the Index Table, 

22 each Index Code is associated with a Staging value. In the Window Table, each unique 

23 combination of Index Code and Staging Indicator value is associated with a Beginning 

24 Window size. 

25 In addition, at 1655, patient records identified with a complicating diagnosis 

26 code are tallied (and flagged to be removed from EOC processing later, at step 1660). 

27 Specifically, in the following segments of the report r_edit function (on page 1 1 of the 

28 program listing), each line item for every patient record in the tempdata table is 

29 checked for ICD-9 codes corresponding to an ICD-9 code having an Indicator value 

30 "C" (from the tmp_index table) and any such records are flagged. 

3 1 open cntjcomplic using Licdl 
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1 fetch cnt_com;lic into ok Jlag 

2 
3 



4 

5 
6 



9 

10 
11 



30 
31 



close cntcomplic 



if ok _Jlag then 



end if 



end if 



7 if not curjeocjisjbad then 
8 

let eoc comp = eoc comp + 1 

let an_eoc_was_bad = true 

let cur_eocisjbad = true 

1 2 let cur status = "C" 
13 
14 
15 
16 

17 Following the flagging of complications at 1655, the program then proceeds 

18 sequentially through the claim line item records in the temp_data table (on a patient- 

19 by-patient basis) and identifies whether or not the applicable clear window period has 

20 expired between any two consecutive records. This algorithm uses the winjnax 

21 variable that was populated earlier in step 1650 with the proper Beginning Window 

22 value for the ICD-9 code on the record. The date of service in each record is compared 

23 with the date of service in the record immediately preceding it chronologically. If the 

24 two records being compared are separated by a time period equal to, or greater than, the 

25 clear window period {win jnax), the later record is identified as the beginning event of 

26 the a new episode of care. This iterative process is continued for all remaining line item 

27 records for all patient claims and is implemented by the following segments of the 

28 report rjedit function (appearing on page 1 1): 

29 ifLdate_of_serv - prevjios >= win max then 



let eoc cnt = eoc cnt + 1 



58 



1 let curjeocjisjbad = false 

2 



3 
4 
5 

6 end if 



leteocjcnt Jor _pat = eoc_cnt Jor j>at + l 
let cur_eoc_num = cur_eoc_num + 1 
let cur status = "V" 



let prevdos = Ldate of serv 



7 
8 
9 
10 

1 1 An alternative embodiment, not implemented in the Microfiche Appendix, can 

12 employ a second process to delineate potential episodes of care. In such embodiment, 
12 the Window table is populated with values in both the Beginning Window and Ending 

14 Window fields. The Ending Window defines a post-episode clear window period, 

15 which may be different from the pre-episode clear window (Beginning Window). In 

16 this manner, an episode of care can be defined relative to asymmetrical clear window 
U time periods. 

I g In the present embodiment, after the program checks that the clear window 

ig period has not been exceeded, the claim line item is associated with a potential episode 

20 and inserted into the eoc table. Once all line items are so processed, the eoc table 

2 1 replaces temp_data as the repository for all patient claims detail information and is 

22 used for all further processing. 

23 c) Remove Patients With Complications 

24 At step 1660, the program removes from further consideration patients having 

25 complications in their medical claims history, as indicated by a flag referred to above in 

26 step 1655. Namely, all records for patients flagged as having complications are deleted 

27 from the eoc table. This step is subsumed within the program statements for the report 

28 rj&dto function. More particularly, the statement "put insjpat_eoc" inserts the patient, 

29 relationship, and sex values for patients identified with complications into a temporary 

30 table, pat_eoc, as specified in the following code, found on page 9 of the program 

31 listing: 
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• 



12 
13 
14 
15 
16 
17 
18 
19 
20 
21 



24 
25 



29 
30 
31 



create temp table pat_eoc ( 

patient char(15), 



1 

2 
3 
4 

^ relationship char(l), 

6 sex char(l)) in userspacel; 

7 
8 
9 

10 

2 1 open ins _pat_eoc 



declare ins _pat_eoc cursor for 

insert into patjeoc values (cpatient, crelationship, csex) 



The following program segment, found on page 6 of the pp_comp.4gl program 
listing, deletes every record from the eoc table containing a patient, relationship and sex 
combination listed in the pat_eoc table, thus removing all of the records for every 
patient who was considered as having complications for the stated medical condition: 

prepare del_comp_eoc from 

"delete from eoc where e_claim_id = ?" 



22 call errorlog ("updating Comp Patients ") 

23 



declare comp _pat_curs cursor for 
select unique e_claim_id 



26 from e_claim cc, pat_eoc pe 

27 wh ere ccpatient = pe.patien t and 

28 



cc. relationship = pe.relationship and 
ccsex = pe.sex 
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foreach comp _pat_curs into c.e_claim_id 



1 
2 
3 
4 

^ execute del_comp_eoc using c.e_claim_id 

6 end foreach 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 

25 open qual_ins 

26 /g/ icount = 0 

27 
28 

• * • 

29 

2Q /e* q. category = " " 

3 1 open get_cat using q. cpt 



call errorlog ("done with comp Patients") 

Thus, at this step, all records for patients having a complication flagged in their 
medical claims history are deleted from the eoc table and removed from further 
consideration for episode or profile building, 
d) Qualify Episodes of Care For Profile Assignment 

At step 1670, each potential episode of care in the eoc table is checked against 
EOC qualifying rules to determine whether the episode will be assigned to a profile. 
Episodes that fail the qualifying rules are not removed from the eoc table; but neither 
are they assigned a profile. Step 1670 is implemented in pertinent part by a foreach 
statement that loops through each record in the eoc table, which, as mentioned 
previously, now contains all claims line item records that have been found to be part of 
a valid episode of care. 

The following statements (including the foreach statement) appears in the 
pp_compAgl program listing beginning on page 7: 



foreach qeocjcurs into cur_eoc_num f q.date_of_serv, q.cpt, qJcdl 
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ificount=0 then 

let prev_eoc = cur_eoc_num 

end if 



1 fetch getjcat into q.category 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 

13 let eoc _profile = 



if cur_eoc_num != preveoc then 
close qual_ins 



, _ « u 



14 
15 
16 
17 
18 

1 9 open qual iiis 

20 



ca// qual-check("E") returning passed, eoc _profile, ruleerr 
execute updjeoc using eoc _profile, prev_eoc 



21 
22 

23 end if 



let prev_eoc = cur_eoc_num 



put qual_ins 
end foreach 



24 
25 
26 
27 
28 

29 Before invoking the foreach statement, the program begin by opening a 

30 temporary table, qual_ins, that is used for storing a patient's records based on the 

31 results of the qualification process (that is, the qual_check function). Thereafter, the 
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1 foreach loop is begun. In the foreach loop, an if/else conditional is used to determine 

2 whether the record being processed is the first patient record in the eoc table, and if so, 

3 initializes the prev_eoc variable to the current EOC number. Thereafter, the 

4 qualcheck function is invoked with a value of "E" in the injscope variable, which 

5 indicates that episode qualifying rules are to be used by the function. 

6 As is set forth in detail in Section (d) above, the qual_check function executes 

7 different logic based on the type of qualifying rules that are associated with the selected 

8 Index Code. For episode qualification, the same three sets of qualifying logic (Type II, 

9 Type IC, Type CC) are employed as in the patient qualification process, except that 

10 access to the qualifying tables (and rules) is determined by the scope value "E" rather 

1 1 than "P". Again, the qualifying rules are defined by the contents of the same set of four 

12 qualifying tables - the Qualifying Master, Qualifying Group, Qualifying Index, and 

13 Qualifying Code tables. For episodes of care, however, the qualifying rules determine 

14 if a potential EOC meets the minimum profiling criteria expected for the selected Index 

15 Code (e.g., episode includes procedure codes indicating surgical services required for 

16 the medical condition). 

17 As compared with its operation in the patient qualification process set forth 

18 above, when executed for episode qualification, the qual check function evaluates 

19 whether the qualifying logic only until the first set of rules are "passed." If any rule is 

20 considered "passed," then the episode currently being processed has qualified for 

21 profiling. The qualjcheck function discontinues episode qualification and returns 

22 control back to the ppjcompAgl program. In addition to the rule j>assed value, the 

23 qualcheck function returns to the main program a value in the eoc ^profile variable, 

24 which profile number {profile jium) is then inserted into the eoc table. The qualcheck 

25 function sets the value of eoc profile to equal the contents of the Profile field of the 

26 Qualifying Master table (qm.profile). If the episode of care does not satisfy the 

27 qualifying criteria, the eoc jprofile variable the episode is not assigned a profile. Thus, 

28 the qual check function not only determines whether the episode may profiled but also 

29 to which profile it belongs. 

30 The profiles assigned to episodes correspond to combinations of treatment 

31 patterns that are likely to arise for a given medical condition. There are eight basic 
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1 profile classes to which an episode of care may be assigned. The profile classes identify 

2 common combinations of treatment patterns that are useful for statistically analyzing 

3 and reporting on medical provider billing data. These Profile Classes are: 

4 0. Common Profile (diagnostic and E/M services common to all of the 

5 above). 



6 


1. 


Surgery/Medicine/Radiation Profile 


7 


2. 


Medicine/Radiation Profile 


8 


3. 


Surgery/Radiation Profile 


9 


4. 


Surgery/Medicine Profile 


10 


5. 


Radiation Profile 


11 


6. 


Medicine Profile 


12 


7. 


Surgery Profile 



13 

14 e) Append Category Information to the EOCs 

15 After all valid EOCs have been assigned to a profile, processing continues at 

16 step 1680 with appending category data to the eoc table records. Specifically, at step 

17 1680, all of the CPT codes in the eoc table records are categorized using the catfile 

18 table created at step 1645. This step involves the re-categorization of all CPT codes but 

19 only in the patient records that have been qualified for episode of care creation during 

20 the previous program step 1670. The functionality is similar to that in step 1670; the 

21 difference being that in step 1680, the category code is appended to the eoc table record, 

22 whereas in step 1670, the category code is held temporarily in a variable to assist in the 

23 EOC profile categorization. (During execution of the foreach loop of step 1670, the 

24 program performs a lookup on the category table based on the procedure code of the 

25 medical record in question to assist in the profile categorization of an episode.) In an 

26 alternative embodiment, not implemented in the Microfiche Appendix, the eoc table 

27 with category information appended is then used to populate the procedure and category 

28 parameter tables, which store historical billing and statistical information by Index 

29 Code. 
30 

31 
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1 

2 f) Populate the Procedure and Category Parameter Tables 

3 In the above-referenced alternative embodiment, at step 1685, data from 

4 qualified eoc table records (that now include category codes) is added to the procedure 

5 and category parameter tables. In general, data from all of the episodes of care for each 

6 Index Code are inserted into parameter tables to allow for summary statistical profiling. 

7 g) Generate Output 

8 In yet another embodiment, statistical profiles and other analysis of the data from all 

9 episodes of care are provided through the generation of output reports, 1690. The 

10 output reports may be implemented as an online table look-up or a hard copy report. 

11 It is to be understood that the above-described embodiments are merely 
1 2 

illustrative of numerous and varied other embodiments which may constitute 

13 

applications of the principles of the invention. Such other embodiments may be readily 

14 

j ^ devised by those skilled in the art without departing from the spirit or scope of this 

16 invention and it is our intent that they be deemed within the scope of our invention. 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 
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